xfsprogs 3.1.12 and 3.2.0 releases?

[Mark Tinguely]

On 01/21/14 17:41, Dave Chinner wrote:
> 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.

Thanks for making the list. I agree with Dave above about 3 feature 
patches and the directory file type changes.

The following patch that is in your "not sure" list looks like a good 
bug fix that is not CRC related:

ba28b64e69ce3a7989df88f71a5cb608b1c71e3 xfs_repair: drop buffer 
reference on symlink error

--Mark.