xfs
[Top] [All Lists]

Re: deep chmod|chown -R begin to start OOMkiller

To: Peter Broadwell <peter@xxxxxxxx>
Subject: Re: deep chmod|chown -R begin to start OOMkiller
From: David Chinner <dgc@xxxxxxx>
Date: Tue, 16 May 2006 15:09:43 +1000
Cc: David Chinner <dgc@xxxxxxx>, Anders Saaby <as@xxxxxxxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <44694306.9030407@wink.com>
References: <4464E3B5.8020602@wink.com> <20060515132936.GN1331387@melbourne.sgi.com> <4468F967.6090202@wink.com> <4464E3B5.8020602@wink.com> <200605151159.34802.as@cohaesio.com> <4468F30E.3030405@wink.com> <20060516013408.GB1390195@melbourne.sgi.com> <44694306.9030407@wink.com>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Mon, May 15, 2006 at 08:12:06PM -0700, Peter Broadwell wrote:
> David Chinner wrote:
> >>In looking around I did see a ioctl, XFS_IOC_FSBULKSTAT, that seemed
> >>like it might give a different approach to doing this, but looked like it
> >>was read only (and lots of work to get anything going with it...)
> >>Is this a worthwhile avenue to look at more deeply?
> >
> >Read only, and does not follow any directory structure - it just reads
> >the inodes off disk in ascending block order....
> 
> Well, *if* I had to do this often I would think a write version of this
> ioctl might reduce by at least 1/3 the number of disk writes, no?

If you wanted to change every inode in the filesystem, then yes, it
could be done this way (e.g. an inode cluster at a time). And the
difference in I/Os would be more like an order of magnitude.

However, a write version is not quite that simple because you still
have to log all the changes you make.....

> It also seems funny that I could copy the whole disk in less time that
> it took me to chown files that are filling up less than 1/2 of it...

Yep, that's the difference between doing large sequential I/Os
for the disk copy and small, random I/Os for the chown...

> Fortunately I don't expect to have to do this again, and if I do,
> I'll know it will be a long running process.
> 
> Thanks again for your help in understanding what is probably happening.

np.

Cheers,

Dave.
-- 
Dave Chinner
R&D Software Enginner
SGI Australian Software Group


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