xfs
[Top] [All Lists]

Re: low level access path for xfs operation

To: kss@xxxxxxxx
Subject: Re: low level access path for xfs operation
From: Jeremy Jackson <jerj@xxxxxxxxxxxx>
Date: 25 Mar 2003 09:30:38 -0500
Cc: Chris Wedgwood <cw@xxxxxxxx>, linux-xfs@xxxxxxxxxxx
In-reply-to: <20030322101427.A32751@xxxxxxxxxxxxx>
Organization:
References: <20030321124047.A26767@xxxxxxxxxxxxx> <20030321091423.A28976@xxxxxxxxxxxxx> <20030321194353.A12729@xxxxxxxxxxxxx> <20030321204052.GB27409@xxxxxxxx> <20030322101427.A32751@xxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
If using EVMS with dm/LVM, it is easy to make another volume.  The
administrator needs to learn the hard way not to fill up the disk with a
filesystem that cannot shrink.  (I know I have) It will create other
problems besides not having room to snapshot.

Sure would be nice if XFS *could* shrink. The other features outweigh
this disadvantage for me.

Jeremy

On Fri, 2003-03-21 at 20:14, Soon-Son Kwon wrote:
> 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
> files.
> 
> > > 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...


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