HEADS UP: New ZFS in the tree.

[Thomas Sparrevohn]

On Friday 21 November 2008 01:19:35 Ivan Voras wrote:
> Thomas Sparrevohn wrote:
> > On Wednesday 19 November 2008 10:14:02 Ivan Voras wrote:
> >> Thomas Sparrevohn wrote:
> >>> On Tuesday 18 November 2008 21:56:38 Pawel Jakub Dawidek wrote:
> >>>> On Tue, Nov 18, 2008 at 09:50:51PM +0000, Thomas Sparrevohn wrote:
> >>>>> On Tuesday 18 November 2008 21:32:44 Pawel Jakub Dawidek wrote:
> >>>>>> What's unexpected in that? As I noted it still needs more work, so
> >>>>>> chflags(2) working properly would be unexpected for me:)
> >>>>>>
> >>>>>>> --------------------------------------------------------------
> >>>>> LOL - Unexpected that it just not returns operation not supported as it used to - I was a bit
> >>>>> trigger happy and upgraded my main pool - against the sound advice - leaves me in a bit of trouble ;-)
> >>>> Try 'make installworld NO_FSCHG='.
> >>>>
> >>> LOL and now I feel really stupid - thanks
> >> Hmmm, I did an installworld from UFS to ZFS yesterday without special
> >> flags (actually, multiple installworlds for benchmarking), without
> >> errors. Files really did get schg (or equivalent) flag since I couldn't
> >> rm them afterwards. How is this possible? :)
> > 
> > That is a surprise - as mine failed - totally - had to manually restore libc
> 
> I've just did it again - make installworld DESTDIR=/data/test (I'm not
> using ZFS on root) - works without problems, ls reports schg flag on the
> usual files. amd64, ZFS pool version 13, compiled a few hours after the
> big import.
> 
> 
> 

Yes it works if you have either created a new pool or made sure that all mountpoints have
the version=3 flag set 

What got me is that zpool upgrade does not change the version of the mountpoints e.g. 
they stay version 1

so a simple 

	foreach i (`zfs list -H -t filesystem -o name `)
		zfs set version=3 
	end

will make schg work