linux-ext4 - Re: fallocate support for bitmap-based files

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]

Date:	Sat, 30 Jun 2007 13:29:21 -0400
From:	Andreas Dilger <adilger@...sterfs.com>
To:	Mingming Cao <cmm@...ibm.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Theodore Ts'o <tytso@....edu>,
	Mike Waychison <mikew@...gle.com>,
	Sreenivasa Busam <sreenivasac@...gle.com>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: fallocate support for bitmap-based files

On Jun 30, 2007  10:13 -0400, Mingming Cao wrote:
> Another approach we have been thinking  is using a backing
> inode(per-inode-with-preallocation) to store the preallocated blocks.
> When user asked for preallocation on the base inode, ext2/3 create a
> temporary backing inode, and it's (pre)allocate the corresponding
> blocks in the backing inode. 
> 
> When writes to the base inode, and realize we need to block allocation
> on, before doing the fs real block allocation, it will check if the file
> has a backing inode stores some preallocated blocks for the same logical
> blocks.  If so, it will transfer the preallocated blocks from backing
> inode to the base inode.
> 
> We need to link the two inodes in some way, maybe store the backing
> inode number via EA in the base inode, and flag the base inode that it
> has a backing inode to get preallocated blocks.
> 
> Since it doesn't change the block mapping on the original file until
> writeout, so it doesn't require a incompat feature to protect the
> preallocated contents to be read in "old" kernel. There some work need
> to be done in e2fsck to understand the backing inode.

I don't know if you realize, but this is half-way to supporting
snapshots within the filesystem.  If there are any serious efforts in
the direction of snapshots, you should start by looking at ext3cow,
which does that already.  I haven't looked at that code yet, but I
worked on a snapshotting ext2 many years ago and it was implemented
nearly as you describe (though backward, moving blocks from the "real"
file to the shadow inode).

The OTHER thing that is important for snapshots, is quite easy to
implement now (it even makes the filesystem more robust), but will be
considerably harder to do later, and something I wish someone could work
on is to add "whiteout" support for extents to allow extents in a file
to explicitly encode a hole in the file to "hide" the contents in a
backing/snapshot inode that was truncated away, as described in my email
"[RFC] extent whiteouts" (that nobody ever commented on).

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
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