public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.com>
To: Mingming Cao <cmm@us.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Theodore Ts'o <tytso@mit.edu>, Mike Waychison <mikew@google.com>,
	Sreenivasa Busam <sreenivasac@google.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: fallocate support for bitmap-based files
Date: Sat, 30 Jun 2007 13:29:21 -0400	[thread overview]
Message-ID: <20070630172921.GB5159@schatzie.adilger.int> (raw)
In-Reply-To: <1183212800.9505.12.camel@localhost.localdomain>

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.

  reply	other threads:[~2007-07-01 16:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-29 20:01 fallocate support for bitmap-based files Andrew Morton
2007-06-29 20:36 ` Dave Kleikamp
2007-06-29 20:52   ` Mike Waychison
2007-06-29 21:24     ` Dave Kleikamp
2007-06-29 20:55 ` Theodore Tso
2007-06-29 21:38   ` Andrew Morton
2007-06-29 22:07     ` Mike Waychison
2007-07-04 23:11       ` Valerie Henson
2007-07-06 21:15         ` Mike Waychison
2007-06-29 21:46   ` Andreas Dilger
2007-06-29 22:26     ` Mike Waychison
2007-06-30  5:14       ` Andreas Dilger
2007-06-30 14:31         ` Mingming Cao
2007-06-30 14:13 ` Mingming Cao
2007-06-30 17:29   ` Andreas Dilger [this message]
2007-07-02 14:44     ` Mingming Cao
2007-07-02 17:44   ` Badari Pulavarty
2007-07-06 21:33     ` Mike Waychison
2007-07-07  2:05       ` Badari Pulavarty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070630172921.GB5159@schatzie.adilger.int \
    --to=adilger@clusterfs.com \
    --cc=akpm@linux-foundation.org \
    --cc=cmm@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=mikew@google.com \
    --cc=sreenivasac@google.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox