On Tue, Jan 21, 2014 at 09:17:38AM +0100, Arkadiusz Miśkiewicz wrote: > On Tuesday 21 of January 2014, Ben Myers wrote: > > On Mon, Jan 20, 2014 at 03:08:14PM -0800, Christoph Hellwig wrote: > > > On Tue, Jan 21, 2014 at 10:02:59AM +1100, Dave Chinner wrote: > > > > Well, that's always been the plan since a 3.1.12 release was > > > > proposed 3 months ago. How well has that plan been working out so > > > > far? > > > > > > The sad part is that I would have had the time 3 month ago, but right > > > now it's hard. Still trying to get it done, though. > > > > If Arkadiusz is willing to provide a list of commits to include it > > shouldn't be a problem to get this done. I believe he indicated a > > willingness to help on IRC earlier today. > > By looking into git log these look like small fixes for 3.1.x. Could someone else recheck? > ..... > 3a19fb7dce9d570e78deaf5c26c0ab8a4a5bef67 libxfs: stop caching inode structures > 61510437c627b529feb95ebffddd73df5ed5b104 repair: prefetching is turned off unnecessarily > 0cce4aa198f0470817bedb3781ea5b6955e43076 repair: Increase default repair parallelism on large filesystems I think these three are not a great idea for 3.1.x. They result in significant changes of behaviour that can result in increased memory consumption by default. I'd prefer that we don't make changes to the default behaviour in a bug-fix only point release. ..... > Not sure about these: > > 1ba28b64e69ce3a7989df88f71a5cb608b1c71e3 xfs_repair: drop buffer reference on symlink error > 4e503735fd407e2e61295e6af6ec47af4693bc95 xfs_repair: fix btree block magic number mapping > 4fbebf374ccc178f1fedcf2d8a43339031f8dbb4 libxfs: fix dir3 freespace block corruption > 494434d7fb79840ba113ecd7fb1ac3ae20e0f569 xfs: Add read-only support for dirent filetype field > 906b762f55333968321062642a0b90feac1fdffb xfs: Add write support for dirent filetype field > 3beed08eb22f56b384d2028541ccb41284ff9751 xfsprogs: add dtype support to mkfs and db > 1acc538540ce22e16bb55ca573691070a8d375db xfsprogs: initialize filetype for xfs_name_dot > 41315687d9db9b50876401e7b0ee20dd77cfc712 xfs: dirent dtype presence is dependent on directory magic numbers > 68774b900e0c8368342cb12f649572a86ef2f6e4 xfsprogs: initialize filetype for lost+found creation > 2cca1dbd1c3e12d270a9baa5f85e548e8a5a2125 xfs_repair: add d_type when moving files to lost+found > 87e343bd0937e5bb75dd8bc46ba388b6f8c6552b xfsprog: add xfs sb v4 support for dirent filetype field > 6f700630b06a2ce15aebe8608b2c5877002299d6 xfsprog: add dirent filetype information for xfs_info > 42737f1ad16213a3dab1756c9fffb494db8ef27e xfs_progs: add dirent filetype to xfs_db version > 4eb02d95b7e081b510a7015609f01385aab229a9 xfsprog: add mkfs.xfs sb v4 support for dirent filetype field I'd say not to the dirent filetype changes. They require the CRC format enabled directory code and that basically involves backporting the entire 3.2-alpha code base to support it. Otherwise a complete re-implementation in needed for 3.1.x, not a backport. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
