[Top] [All Lists]

Re: xfsprogs 3.1.12 and 3.2.0 releases?

To: Dave Chinner <david@xxxxxxxxxxxxx>, Arkadiusz MiÅkiewicz <arekm@xxxxxxxx>
Subject: Re: xfsprogs 3.1.12 and 3.2.0 releases?
From: Rich Johnston <rjohnston@xxxxxxx>
Date: Thu, 23 Jan 2014 16:37:21 -0600
Cc: <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140122230356.GD27606@dastard>
References: <201401201822.48520.arekm@xxxxxxxx> <201401210917.38674.arekm@xxxxxxxx> <20140121234151.GJ13997@dastard> <201401221548.52273.arekm@xxxxxxxx> <20140122230356.GD27606@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 01/22/2014 05:03 PM, Dave Chinner wrote:
On Wed, Jan 22, 2014 at 03:48:52PM +0100, Arkadiusz MiÅkiewicz wrote:
On Wednesday 22 of January 2014, Dave Chinner wrote:
On Tue, Jan 21, 2014 at 09:17:38AM +0100, Arkadiusz MiÅkiewicz wrote:

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.

3a19fb7dce9d570e78deaf5c26c0ab8a4a5bef67 libxfs: stop caching inode

looks like wasting memory fix to me but ok.

The last paragraph ofi the commit message points out the problems
that can occur with memory consumption. For sparse inode
populations, the buffer cache can consume much more memory than the
inode cache did, and that can cause OOM problems with repair...

As it is, it is a significant change of behaviour, so for a
lightweight bug-fix only release I feel that it is out-of-scope...



I'll get this put together by Monday unless someone else wants to do it.


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