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

[Jeff Garzik]

Joe Thornber wrote:
> 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.

A popular way which also resolves atomicity issues is to just have a 
'control' file, to which you write(2) a command code and 
command-specific data, and read(2) results of the operation (if any). 
This would allow you to do a new-table command, a suspend command, a 
resume-with-existing-table command, a resume-with-new-table command, 
etc.  In other words, a more flexible ioctl(2) ;-)

Preferred method of data input is always ASCII, but if that is 
unreasonable, make sure your binary data is fixed-endian and fixed-size 
on all architectures.

	Jeff