[Top] [All Lists]

Re: low level access path for xfs operation

To: Chris Wedgwood <cw@xxxxxxxx>
Subject: Re: low level access path for xfs operation
From: Soon-Son Kwon <kss@xxxxxxxx>
Date: Sat, 22 Mar 2003 10:14:27 +0900
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <20030321204052.GB27409@f00f.org>; from cw@f00f.org on Fri, Mar 21, 2003 at 12:40:52PM -0800
Organization: KLDP(Korean Linux Documentation Project)
References: <20030321124047.A26767@mail.kldp.org> <20030321091423.A28976@infradead.org> <20030321194353.A12729@mail.kldp.org> <20030321204052.GB27409@f00f.org>
Reply-to: kss@xxxxxxxx
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
On Fri, Mar 21, 2003 at 12:40:52PM -0800, Chris Wedgwood wrote:
> On Fri, Mar 21, 2003 at 07:43:53PM +0900, Soon-Son Kwon wrote:
> > What I would like to implement is the snapshot functionality within
> > the filesystem. I know LVM supports snapshot but it requires a
> > separate volume for each snapshot. I thought snapshot within the
> > filesystem would be more convenient.
> How should this work from a user perspective?

If a snapshot can be generated/maintained within the filesystem,
the user do not have to care for the overall disk layout as long
as there are some free spaces in the filesystem while LVM
requires additional volume which means even if there are a lot of
of free blocks on the source filesystem, the user should allocate
another volume for the snapshot. This can be a problem if the
system administrator had allocated all the blocks to some
volumes already because he/she cannot generate volume for snapshot
any more.

And the snapshot does not affect anything to normal users.
What snapshot can provide to the users are he/she can revert
the filesystem to the state when the snapshot was taken
which means the user can get an older version of file or deleted

> > Snapshot functionality requires copy-on-write implementation when
> > something tries to modify any block, copy the old content to new
> > block and overwrite the new content to that block while the snapshot
> > image keeps track of the original content.
> You need to be sure whatever mechanism you use to keep track of block
> placements is efficient and the granularity are sane or else the
> metadata to keep track of this can be enormous.
> > Anyway, do you think implementing that operation requires modifying
> > dm/md code instead of modifying submit_bio()?
> No... I don't see why it should --- ideally you want a pseudo-block
> device or similar to place the fs on; this will then be able to track
> changes and such like.
> Check the device-mapper and LVM as they effectively do this.

So, you mean the following design as follows?

(VFS)-(XFS)-(pseudo-block device)-(md)-(dm)

I just thought if I can be notified any write/modify operation for
a block, then I can copy and allocate the old block to a new location
and record that information to the snapshot file, then the original
block contents can be (over)written.

(of course when generating a snapshot information, it should
store every information on which block was in use/free at that time
the snapshot was taken as a form of something like block map.)

But anyway I am not an expert on this field. 
Could you please give a little more detailed explanation of
the "pseudo block device" or any comment on my descriptions above?

Thank you very much...
           (o_             **WTFM**
(o_  (o_   //\
(/)_ (/)_  V_/_        http://kldp.org

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