linux-ext4 - RE: [RFC] Ext3 online defrag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200610250225.MAA23029@larry.melbourne.sgi.com>
Date:	Wed, 25 Oct 2006 12:30:02 +1000
From:	"Barry Naujok" <bnaujok@...bourne.sgi.com>
To:	"'David Chinner'" <dgc@....com>,
	"'Dave Kleikamp'" <shaggy@...tin.ibm.com>
Cc:	"'Jeff Garzik'" <jeff@...zik.org>,
	"'Alex Tomas'" <alex@...sterfs.com>,
	"'Theodore Tso'" <tytso@....edu>, "'Jan Kara'" <jack@...e.cz>,
	<linux-fsdevel@...r.kernel.org>, <linux-ext4@...r.kernel.org>
Subject: RE: [RFC] Ext3 online defrag

 

On Wed, 25 Oct 2006 11:19 AM, David Chinner wrote:
> On Tue, Oct 24, 2006 at 11:26:26AM -0500, Dave Kleikamp wrote:
> > On Wed, 2006-10-25 at 02:01 +1000, David Chinner wrote:
> > > On Tue, Oct 24, 2006 at 09:51:41AM -0500, Dave Kleikamp wrote:
> > > The allocation interface needs to be be able to be  extended
> > > independently of the data mover interface. XFS already exposes
> > > allocation ioctls to userspace for preallocation and 
> we've got plans
> > > to extnd this further to allow userspace controlled allocation for
> > > smart defrag tools for XFS. Tying allocation to the data mover
> > > just makes the interface less flexible and harder to do anything
> > > smart with....
> > 
> > Okay.  It would be nice to standardize the interface so we 
> don't have
> > every filesystem introducing new ioctls.
> 
> Well, that will be an interesting challenge. I'm sure that there
> is a common subset that all filesystems can implement e.g. per
> file preallocation (something like XFS's allocate/reserve/free space
> ioctls) to provide kernel support for posix_fallocate(), etc.
> 
> However, we may end up exposing enough of XFS's current allocation
> semantics to do things like telling the filesystem to allocate in
> allocation group 6, near block number 0x32482 within the AG, falling
> back to searching for the nearest match to the size requirement,
> failing that look for something larger than the minimum size
> specified, and then fail if you can't find a match in that AG.
> 
> That makes little sense to any filesystem but XFS, which is really
> why I think that the smarter allocation interfaces are going to
> remain filesystem specific....

Could we have a more abstract method for asking the filesystem where the 
free blocks are and then using the same block addressing to tell the
fs where to allocate/move the file's data to?

-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html