projid32bit=1 default in xfsprogs-3.2.0

The commit:

f3edb66a mkfs.xfs: validate options for CRCs up front.

unintentionally (?) defaulted to projid32bit=1 for all filesystems at mkfs time.

Support for 32 bit project IDs has been present since kernel v2.6.37.

Quoted 6 lines · Eric Sandeen

The commit:

f3edb66a mkfs.xfs: validate options for CRCs up front.

unintentionally (?) defaulted to projid32bit=1 for all filesystems at mkfs time.

It wasn't unintentional, I just forgot to document it.

Quoted 1 line

Support for 32 bit project IDs has been present since kernel v2.6.37.

Right, so taking the usual approach to these things, all the distro's now ship kernels that support 32 bit project IDs, so there is no reason for mkfs.xfs in a new xfsprogs release not to set it by default.

Quoted 8 lines · Dave Chinner

Quoted 6 lines · Eric Sandeen

The commit:

f3edb66a mkfs.xfs: validate options for CRCs up front.

unintentionally (?) defaulted to projid32bit=1 for all filesystems at mkfs time.

Quoted 8 lines

It wasn't unintentional, I just forgot to document it.

Quoted 1 line

Support for 32 bit project IDs has been present since kernel v2.6.37.

Right, so taking the usual approach to these things, all the distro's now ship kernels that support 32 bit project IDs, so there is no reason for mkfs.xfs in a new xfsprogs release not to set it by default.

I'm not seeing much downside to turning on 32 bit project IDs by default in 3.2.0. Sounds good to me.

-Ben

Ok. Default it is! Thanks guys, just wanted to make sure we were
all in agreement there.

Quoted 2 lines · Eric Sandeen

Ok. Default it is! Thanks guys, just wanted to make sure we were
all in agreement there.

Can we make sure this gets documented in doc/CHANGES?

I'm also pretty sure the entry for 3.2.0-alpha1 is severly lacking, can we make sure the one for the real release is as detailed as the ones for the previous releases?

Quoted 6 lines · Christoph Hellwig

Quoted 2 lines · Eric Sandeen

Ok. Default it is! Thanks guys, just wanted to make sure we were
all in agreement there.

Can we make sure this gets documented in doc/CHANGES?

Quoted 3 lines

I'm also pretty sure the entry for 3.2.0-alpha1 is severly lacking, can we make sure the one for the real release is as detailed as the ones for the previous releases?

Btw, I also noticed releases after 3.1.9 aren't tagged in git, any chance we could fix that? The release.sh script was supposed to take care of this automatically.

Also we have tons of fixes in the xfsprogs repo that really should go out into a new 3.1.12 release:

xfs_io: v8 add the lseek() SEEK_DATA/SEEK_HOLE support
xfs_db: add header to freesp -d output
xfs_repair: zero out unused parts of superblocks
xfs_repair: add prototype for alloc_ex_data()
xfsprogs: fix Out-of-bounds access in repair/dinode.c
xfsprogs: fix inode crash in xfs_repair
xfsprogs: fix unint var in repair phase6
xfsprogs: fix agcnts leak in xfs_repair's scan_ags xfsprogs:free bp in xlog_find_tail() error path
xfsprogs: free bp in xlog_find_zeroed() error path
xfsprogs: fix buffer leak in xlog_print_find_oldest
xfsprogs: avoid double-free in xfs_attr_node_addname xfsprogs/io: add readdir command
mkfs.xfs: fix protofile name create block reservation
logprint: fix wrapped log dump issue
xfs_metadump: manpage fix regarding frozen fs
mkfs: add missing noalign suboption information
xfsprogs: fix make deb
xfsprogs: define umode_t for build if not defined already
xfs_logprint: fix continuation transactions
xfs_fsr: file reads should be O_DIRECT
xfs_logprint: print all AGI unlinked buckets

+ a few more pending on the list. I'd volunteer to prepare and test thos backports once we get the remaining patches from the list in.

The tags are out there:
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=tags

That's an interesting idea. We hadn't discussed a 3.1.12 release. No particular objection to doing that, it's just that we didn't branch for the v3.0.5->v3.1.0 set of releases. Maybe it is better if we all focus on 3.2.0.

Quoted 2 lines · Ben Myers

The tags are out there:
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=tags

I managed to somehow miss them. Sorry!

Quoted 3 lines

That's an interesting idea. We hadn't discussed a 3.1.12 release. No particular objection to doing that, it's just that we didn't branch for the v3.0.5->v3.1.0 set of releases. Maybe it is better if we all focus on 3.2.0.

With git you can easily branch from a past commit, e.g.:

hch@brick:~/work/xfsprogs$ git checkout -b release-3.1 v3.1.11
Switched to a new branch 'release-3.1'

Hey,

Quoted 5 lines · Christoph Hellwig

Quoted 2 lines · Ben Myers

The tags are out there:
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=tags

I managed to somehow miss them. Sorry!

np

Quoted 4 lines

Quoted 3 lines

That's an interesting idea. We hadn't discussed a 3.1.12 release. No particular objection to doing that, it's just that we didn't branch for the v3.0.5->v3.1.0 set of releases. Maybe it is better if we all focus on 3.2.0.

Quoted 4 lines

With git you can easily branch from a past commit, e.g.:

hch@brick:~/work/xfsprogs$ git checkout -b release-3.1 v3.1.11
Switched to a new branch 'release-3.1'

Yep. If folks want a 3.1.12 we should certainly kick the idea around a bit. I'm just guessing that most would prefer to focus on a 3.2.0 in the near term. Maybe I'm mistaken about that though. ;)

Thanks,
Ben

Quoted 20 lines · Ben Myers

Hey,

Quoted 5 lines · Christoph Hellwig

Quoted 2 lines · Ben Myers

The tags are out there:
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=tags

I managed to somehow miss them. Sorry!

np

Quoted 8 lines

Quoted 3 lines

That's an interesting idea. We hadn't discussed a 3.1.12 release. No particular objection to doing that, it's just that we didn't branch for the v3.0.5->v3.1.0 set of releases. Maybe it is better if we all focus on 3.2.0.

With git you can easily branch from a past commit, e.g.:

hch@brick:~/work/xfsprogs$ git checkout -b release-3.1 v3.1.11
Switched to a new branch 'release-3.1'

Quoted 3 lines

Yep. If folks want a 3.1.12 we should certainly kick the idea around a bit. I'm just guessing that most would prefer to focus on a 3.2.0 in the near term. Maybe I'm mistaken about that though. ;)

I'm not super keen to divide the focus; I've already updated the distros I care about to 3.2.0-alpha1, so I wouldn't go backwards to a 3.1.12.

Quoted 25 lines · Eric Sandeen

Quoted 23 lines · Ben Myers

Hey,

Quoted 5 lines · Christoph Hellwig

Quoted 2 lines · Ben Myers

The tags are out there:
http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=tags

I managed to somehow miss them. Sorry!

np

Quoted 8 lines

Quoted 3 lines

That's an interesting idea. We hadn't discussed a 3.1.12 release. No particular objection to doing that, it's just that we didn't branch for the v3.0.5->v3.1.0 set of releases. Maybe it is better if we all focus on 3.2.0.

With git you can easily branch from a past commit, e.g.:

hch@brick:~/work/xfsprogs$ git checkout -b release-3.1 v3.1.11
Switched to a new branch 'release-3.1'

Yep. If folks want a 3.1.12 we should certainly kick the idea around a bit. I'm just guessing that most would prefer to focus on a 3.2.0 in the near term. Maybe I'm mistaken about that though. ;)

Quoted 2 lines

I'm not super keen to divide the focus; I've already updated the distros I care about to 3.2.0-alpha1, so I wouldn't go backwards to a 3.1.12.

I'd prefer we focus on getting stuff reviewed and integrated into 3.2.0 more quickly than we are now. At this point in the cycle, we really need the 3.2 branch and xfstests to be updated daily with the changes that were reviewed in the past 24 hours so that we can iterate test cycles with the latest fixes more easily.

This will give us a clearer idea of the problems we still need to fix before the release can progress without everyone having to keep their own private trees up to date with what everyone else is changing/fixing...

Cheers,

Dave.

Quoted 9 lines · Christoph Hellwig

Quoted 2 lines · Eric Sandeen

Ok. Default it is! Thanks guys, just wanted to make sure we were
all in agreement there.

Can we make sure this gets documented in doc/CHANGES?

I'm also pretty sure the entry for 3.2.0-alpha1 is severly lacking, can we make sure the one for the real release is as detailed as the ones for the previous releases?

Btw, I also noticed releases after 3.1.9 aren't tagged in git, any chance we could fix that? The release.sh script was supposed to take care of this automatically.

Also we have tons of fixes in the xfsprogs repo that really should go out into a new 3.1.12 release:

xfs_io: v8 add the lseek() SEEK_DATA/SEEK_HOLE support
xfs_db: add header to freesp -d output
xfs_repair: zero out unused parts of superblocks
xfs_repair: add prototype for alloc_ex_data()
xfsprogs: fix Out-of-bounds access in repair/dinode.c
xfsprogs: fix inode crash in xfs_repair
xfsprogs: fix unint var in repair phase6
xfsprogs: fix agcnts leak in xfs_repair's scan_ags xfsprogs:free bp in xlog_find_tail() error path
xfsprogs: free bp in xlog_find_zeroed() error path
xfsprogs: fix buffer leak in xlog_print_find_oldest
xfsprogs: avoid double-free in xfs_attr_node_addname xfsprogs/io: add readdir command
mkfs.xfs: fix protofile name create block reservation
logprint: fix wrapped log dump issue
xfs_metadump: manpage fix regarding frozen fs
mkfs: add missing noalign suboption information
xfsprogs: fix make deb
xfsprogs: define umode_t for build if not defined already
xfs_logprint: fix continuation transactions
xfs_fsr: file reads should be O_DIRECT
xfs_logprint: print all AGI unlinked buckets

+ a few more pending on the list. I'd volunteer to prepare and test thos backports once we get the remaining patches from the list in.

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

If your still interested in a 3.1.12 release, a 'for-3.1.12' branch has been created.
http://oss.sgi.com/archives/xfs/2014-01/msg00056.html