Re: [PATCH] Device-mapper submission 6/7

[Joe Thornber]

On Thu, Oct 17, 2002 at 10:26:44AM +0200, Andi Kleen wrote:
> Joe Thornber <[e-mail]> writes:
> 
> > Is there anyone out there who is going to argue against using an fs
> > interface when I submit it ?  Speak now or forever hold your peace !
> > 
> > If dm now misses the feature freeze deadline due to this extra work,
> > is it going to be possible to still place it in 2.5 at a later date ?
> > (dm with an ioctl interface is better than no dm at all).
> 
> How would the fs based interface work ? 
> 
> plan9 style echo 'rename foo bla' > /dmfs/command would seem ugly to me
> (just look at the horrible parser code for that in mtrr.c) 
> 
> doing it fully as fs objects (mv /dmfs/volume1 /dmfs/volume2 for rename)
> could likely get complicated and it's doubtful that VFS semantics completely
> map to DM volumes.

I'll describe what Steve Whitehouse had working before:

Each directory would represent a single device, the name of the
directory names the device (so yes, a mv renames the device).  Inside
each directory are a collection of files:

TABLE - People just cat the table to here to load a mapping.  They can
read it to get the mapping back.

INFO - General information about the device, is it suspended, how many
people have it open etc.

STATUS - One line of information per target, people can poll on this
file in order to block until something 'interesting' happens (eg, an
initial mirror sync completes, a snapshot uses up another 5% of
space).

The thing I'm not sure about is how to map the supend/resume semantics
onto the fs.  It is tempting to bind suspend to an writeable open of
the TABLE file, and resume to the closing of the device.  However that
means that closing the device both indicates the end of the table and
a resume, I'm not sure that is good enough, eg, if the table is bogus
we don't neccessarily want to automatically resume the old table.  So
this leads us to start thinking about a sepearate SUSPENDED file that
we write a 1 or 0 to, yuck.

> Unless you have a clear and simple way to handle these issues I would
> suggest to stay with simple ioctls. They look clean enough.

Linus, any chance you could indicate the preferred direction ?

- Joe