linux-ext4 - Re: [RFC] Defragmentation interface

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <1162565444.8604.7.camel@kleikamp.austin.ibm.com>
Date:	Fri, 03 Nov 2006 08:50:44 -0600
From:	Dave Kleikamp <shaggy@...tin.ibm.com>
To:	David Chinner <dgc@....com>
Cc:	Jan Kara <jack@...e.cz>, linux-fsdevel@...r.kernel.org,
	linux-ext4@...r.kernel.org
Subject: Re: [RFC] Defragmentation interface

On Fri, 2006-11-03 at 09:59 +1100, David Chinner wrote:

> Let me get this straight - the interface you propose for
> moving data about is:
> 
> 	read and process extents into an internal structure
> 	find range where you want to relocate
> 	find free space you want to relocate into
> 	write desired block to alloc_goal
> 	seek to allocation offset in data/alloc
> 	write length into data/alloc
> 	allocate new inode
> 	write new inode number into data/reloc to relocate blocks
> 
> What I proposed:
> 
> 	fcntl(src, FIBMAP);
> 	/* find range to relocate */
> 	open(tmp, O_CREATE);
> 	funlink(tmp);
> 	fs_get_free_list(src, policy, list);
> 	/* select free extent to use */
> 	fs_allocate_space(tmp, list[X], off, len);
> 	fs_move_data(src, tmp, off, len);
> 	close(tmp);
> 	close(src);
> 
> So the process is pretty close to the same except the interface I
> proposed does not change the location of the inode holding the data.
> The major difference is that one implementation requires 3 new
> generically useful syscalls, and the other requires every filesystem
> to implement a metadata filesystem and require root priviledges
> to use.

I agree with Dave here.  The metadata filesystem will require a lot of
overhead (and a lot of code) both in the kernel and in user-space.  The
only benefit I see, is that it can be easily extended.  This may be
useful for debugging and prototyping, but I don't like it as a solution
for adding a permanent interface.

Shaggy
-- 
David Kleikamp
IBM Linux Technology Center

-
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