xfs
[Top] [All Lists]

Re: xfsprogs 3.1.12 and 3.2.0 releases?

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: xfsprogs 3.1.12 and 3.2.0 releases?
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Wed, 22 Jan 2014 08:38:57 -0600
Cc: Arkadiusz MiÅkiewicz <arekm@xxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140121234151.GJ13997@dastard>
References: <201401201822.48520.arekm@xxxxxxxx> <20140120230814.GA4287@xxxxxxxxxxxxx> <20140120231158.GL1935@xxxxxxx> <201401210917.38674.arekm@xxxxxxxx> <20140121234151.GJ13997@dastard>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
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.

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