xfs
[Top] [All Lists]

Re: status of userspace release

To: Ben Myers <bpm@xxxxxxx>
Subject: Re: status of userspace release
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Sat, 3 Nov 2012 11:16:39 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20121102230334.GA29378@dastard>
References: <20121025151501.GV1377@xxxxxxx> <20121102055102.GY29378@dastard> <20121102185923.GG9783@xxxxxxx> <20121102230334.GA29378@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Sat, Nov 03, 2012 at 10:03:34AM +1100, Dave Chinner wrote:
> On Fri, Nov 02, 2012 at 01:59:23PM -0500, Ben Myers wrote:
> > Hi Dave,
> > 
> > On Fri, Nov 02, 2012 at 04:51:02PM +1100, Dave Chinner wrote:
> > > On Thu, Oct 25, 2012 at 10:15:01AM -0500, Ben Myers wrote:
> > > > Hi Folks,
> > > > 
> > > > We're working toward a userspace release this month.  There are several 
> > > > patches
> > > > that need to go in first, including backing out the xfsdump format 
> > > > version bump
> > > > from Eric, fixes for the makefiles from Mike, and the Polish language 
> > > > update
> > > > for xfsdump from Jakub.  If anyone knows of something else we need, now 
> > > > is the
> > > > time to flame about it.  I will take a look around for other important 
> > > > patches
> > > > too.
....
> > The TODO list for userspace release currently stands at:
> > 
> > 1) fix the header checksum failures... which is resolved
> > 2) fix a futex hang in 059
> > 3) fix the golden output changes related to multistream support in xfsdump
> >    and --largefs
> 
> Well, understand them first, then fix ;)
> 
> > 4) test on more platforms

Another:

$ sudo xfs_info /mnt/scratch/
meta-data=/dev/vdc               isize=256    agcount=4, agsize=12800 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=51200, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=1200, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
$ sudo xfs_db -r -c "sb 0" -c "version" /dev/vdc
versionnum [0xb4a4+0x8a] = 
V4,NLINK,ALIGN,DIRV2,LOGV2,EXTFLG,MOREBITS,ATTR2,LAZYSBCOUNT,PROJID32BIT
$

xfs_info is not reporting the 32 bit project ID status.

Yes, I know this requires the XFS_IOC_FSGEOM support for it, but I'd
like it this release to at least say "off or unknown" here.

I say this, because this is the first thing I noticed when having a
look at a test 287 failure:

7 10s ... - output mismatch (see 287.out.bad)
--- 287.out     2012-10-05 11:38:08.000000000 +1000
+++ 287.out.bad 2012-11-03 10:55:15.000000000 +1100
@@ -2,22 +2,24 @@
 No 32bit project quotas:
 projid = 1234
 projid = 0
+xfs_quota: cannot set project on /mnt/scratch/pquota/32bit: Invalid argument
 With 32bit project quota support:
 projid = 1234
-projid = 2123456789
+projid = 0
+xfs_quota: cannot set project on /mnt/scratch/restore/pquota/32bitv2: Invalid 
argument
 The restored file system + one additional file:
 projid = 1234
-projid = 2123456789
-projid = 2123456789
+projid = 0
+projid = 0
 These two values of 16bit project quota ids shall be the same
-core.projid_lo = 1234
+core.projid_lo = 0
 core.projid_hi = 0
 core.projid_lo = 1234
 core.projid_hi = 0
 These three values of 32bit project quota ids shall be the same
-core.projid_lo = 24853
-core.projid_hi = 32401
-core.projid_lo = 24853
-core.projid_hi = 32401
-core.projid_lo = 24853
-core.projid_hi = 32401
+core.projid_lo = 0
+core.projid_hi = 0
+core.projid_lo = 0
+core.projid_hi = 0
+core.projid_lo = 0
+core.projid_hi = 0

Here's what's curious - this is failing on the 17TB filesystem, but
is not failing on 10-20GB filesystems. There seems to be a pattern
here....

Note that I only recently updated xfstests on the VM with the 17TB
filesystem (i.e. on wednesday), so this is probably the first time I
have run test 287 on a large filesystem like this. Same goes for
much of the other problems I'm reporting - xfstests on this machine
has been running out of dev branch I hadn't updated for a while, so
these problems might have been around for a while on large
filesystems...

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>