Request: removal of fs/fs.h/super_block.u to enable partition locking

Request: removal of fs/fs.h/super_block.u to enable partition locking

[Mark Swanson]

Why?

So I can write and distribute a GPL'd 'inuse' filesystem module
that essentially registers a partition as in-use.

I am writing an application that uses raw I/O and I need
some way of locking a partition. The only
way I know of (sortof) doing this is by registering a filesystem
for the partition so system utilities won't overwrite the partition
because they will see it is busy by examining /proc/partitions.

lockf()
on /dev/hda1 doesn't stop root from mounting the partition
as a swap partition or accidentally formatting it
even though the root partition was mounted with 'mand' to 
enable mandatory locking and a 'chmod 2660 /dev/hda1' was done 
to enable mandatory locking on the file.

I'm trying to look out for tired sys-admins who might 
destroy my application's partition not knowing
what a particular empty-looking partition is used for.

Thoughts?

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: Request: removal of fs/fs.h/super_block.u to enable partition locking

[Andreas Dilger]

On Sep 18, 2001  22:14 -0400, Mark Swanson wrote:
> Why?
> 
> So I can write and distribute a GPL'd 'inuse' filesystem module
> that essentially registers a partition as in-use.

I have often thought of the same thing.  In fact, for ext3 journals
which live on their own partition, I ended up creating a filesystem
for them for this reason, among others.  The other benefits of a
filesystem for the journal device is that it could be used to get/set
parameters for the journal daemon via read/write (e.g. (un)registering
or showing journal clients (ext3 filesystems), setting the flush
interval or other tuning parameters, etc).

> I am writing an application that uses raw I/O and I need
> some way of locking a partition. The only
> way I know of (sortof) doing this is by registering a filesystem
> for the partition so system utilities won't overwrite the partition
> because they will see it is busy by examining /proc/partitions.

Do you mean /proc/mounts here instead of /proc/partitions?  The latter
doesn't tell you anything about whether it is in use or not, only if
it has a recognised partition type.  Also, /proc/mounts is only useful
if the device is actually mounted.

> lockf()
> on /dev/hda1 doesn't stop root from mounting the partition
> as a swap partition or accidentally formatting it
> even though the root partition was mounted with 'mand' to 
> enable mandatory locking and a 'chmod 2660 /dev/hda1' was done 
> to enable mandatory locking on the file.

I don't know what the intended semantics of lockf() on a block device
are.  I suppose you could make the kernel/mount check for such locks
when trying to mount a filesystem, but that doesn't prevent mkfs from
killing it unless open() of the device is also blocked by this lock.

I guess if a patch to do this is clean enough it may make it into the
kernel, but AFAIK the POSIX locking code is rather convoluted.  It
would also be the case that the locks are only valid while the program
that locked them is running, so if it dies or is never started, the
devices could be overwritten at that time as well, but at least you
are safe most of the time.

> I'm trying to look out for tired sys-admins who might 
> destroy my application's partition not knowing
> what a particular empty-looking partition is used for.

A real danger, of course.  However, in the end you can't protect users
from destroying things if they want to.  If it is too fool-proof, it
will likely also cause people who DO know what they are doing grief
(e.g. they want to stop using a disk for your app, or there is a real
problem and they need to fix it but can't, like restoring a backup).

One (kind of convoluted) option is to use IBM's EVMS code (which is a
virtual volume manager like LVM) and create a module which recognises
partitions from your application, and then does not export them out to
the users.  They would need to use the EVMS user interface (or you could
integrate your application to the EVMS user tools) in order to unregister
a partition/disk from your app.  This assumes the users have EVMS (which
is slim to none so far).

IBM is also worried about such things as users shooting themselves
in the foot.  However, it would likely still be possible for users to
access the "raw" device inode (e.g. /dev/hda) and overwrite the data.
At one point we discussed EVMS hooking into the block device struct
and preventing it from being written to directly if it was registered
to a higher layer in EVMS, but I doubt that is currently implemented.
This was intended to prevent, for example, writing directly to
/dev/hda1 when that is actually part of an LV or RAID device.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: Request: removal of fs/fs.h/super_block.u to enable partition locking

[Alan Cox]

> I'm trying to look out for tired sys-admins who might 
> destroy my application's partition not knowing
> what a particular empty-looking partition is used for.

You are not going to stop a tired sysadmin doing something daft. You can
certainly create a GPL'd raw partition as a file fs (I believe someone did
that so INN could mmap raw on a device)

However you don't need to remove anything for that

Re: Request: removal of fs/fs.h/super_block.u to enable partition locking

[Mark Swanson]

Alan Cox wrote:
> 
> You are not going to stop a tired sysadmin doing something daft. You can
> certainly create a GPL'd raw partition as a file fs (I believe someone did
> that so INN could mmap raw on a device)
> 
> However you don't need to remove anything for that

But I can't distribute the file fs with my application,
because I can't expect my
user base to patch and recompile their kernel just so they can run
my application.

Perhaps what is needed is an 'inuse' filesystem or a way to make 
filesystem modules without patching the kernel. 

My concern is that ordinary tools like mount check the proc filesystem
to see if a partition is already mounted and it seems likely that tools
like mke2fs do this too. Sysadmins might feel that existing tools
protect
them from damaging something in use. I'm looking for a way to follow
this
general behavior with raw partitions.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: Request: removal of fs/fs.h/super_block.u to enable partition locking

[Andreas Dilger]

On Sep 19, 2001  20:28 +0100, Alan Cox wrote:
> > [Re: removing the fs union from struct inode]
> 
> However you don't need to remove anything for that

No, but there are other things which will probably remove the union from
struct inode in 2.5.  Since it is starting to get so huge, it is a penalty
for filesystems that don't need all of this space in each inode.  Al Viro
has patches already to move some of the fs types into their own slab cache.

It may make sense to leave a small number of bytes inside the inode struct
(they would be used anyways for alignment/padding in the inode slab) for
filesystems that only have very small space requirements.

If you move the union to an external declaration, you can do things like:

static inline struct fs_inode_info *FSI(inode)
{
	if (sizeof(union inode_fs_data) >= sizeof(struct fs_inode_info))
		return (struct fs_inode_info *)&inode->u.generic_ip;
	else
		return (struct fs_inode_info *)inode->u.generic_ip;
}

and the compiler should pick one or the other by virtue of the fact that
it is comparing constants which can be resolved at compile time.  Sadly
sizeof cannot be handled by the preprocessor so the following does not work:

#if sizeof(union inode_fs_data) >= sizeof(struct fs_inode_info)
#define FSI(inode) ((struct fs_inode_info *)&(inode)->u.generic_ip);
#else
#define FSI(inode) ((struct fs_inode_info *)(inode)->u.generic_ip);
#endif

which would guarantee that we do not bloat the code or impose run-time
overhead.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: Request: removal of fs/fs.h/super_block.u to enable partition

[Alan Cox]

> > You are not going to stop a tired sysadmin doing something daft. You can
> > certainly create a GPL'd raw partition as a file fs (I believe someone did
> > that so INN could mmap raw on a device)
> > 
> > However you don't need to remove anything for that
> 
> But I can't distribute the file fs with my application,
> because I can't expect my
> user base to patch and recompile their kernel just so they can run
> my application.
> 
> Perhaps what is needed is an 'inuse' filesystem or a way to make 
> filesystem modules without patching the kernel. 

Apart from the fact that the interface is source level you already can
distribute, compile and merge file systems without patching the kernel.

It seems to be a user space issue not a kernel one. Your app can amend
/etc/mtab when it creates and shuts down. 

Alan

Re: Request: removal of fs/fs.h/super_block.u to enable partition locking

[Andreas Dilger]

On Sep 19, 2001  15:50 -0400, Mark Swanson wrote:
> > However you don't need to remove anything for that
> 
> But I can't distribute the file fs with my application, because I can't
> expect my user base to patch and recompile their kernel just so they can
> run my application.
> 
> Perhaps what is needed is an 'inuse' filesystem or a way to make 
> filesystem modules without patching the kernel. 

You don't need to patch the kernel to add a new filesystem type.  It
is possible to just use "&inode->u.generic_ip" as your filesystem
private inode storage (if you actually need any, which is unlikely with
such a simple filesystem).  All of the other VFS interfaces are exported
to modules, so it is possible to just insert a module to add your fs
type.

When I was doing this (compiling a filesystem that is not part of the
kernel), we used the pcmcia-cs configure scripts to get all of the
relevant kernel config options.  This can be done on a running kernel
without having the actual kernel sources, and if you do this as part
of the startup for your application, you can cache the kernel version
string (from /proc/version) to ensure that the module is always OK
for the current kernel.

Of course, if your code is good enough it may just make it into the
kernel.

> My concern is that ordinary tools like mount check the proc filesystem
> to see if a partition is already mounted and it seems likely that tools
> like mke2fs do this too. Sysadmins might feel that existing tools
> protect them from damaging something in use. I'm looking for a way to
> follow this general behavior with raw partitions.

You are correct.  mke2fs refuses to run on a device where a filesystem
appears to be mounted (either in /proc/mounts or /etc/mtab), unless
you force it to do so.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: Request: removal of fs/fs.h/super_block.u to enable partition

[Andreas Dilger]

On Sep 19, 2001  22:52 +0100, Alan Cox wrote:
> Apart from the fact that the interface is source level you already can
> distribute, compile and merge file systems without patching the kernel.
> 
> It seems to be a user space issue not a kernel one. Your app can amend
> /etc/mtab when it creates and shuts down. 

Well, in recent versions of e2fsprogs it prefers to check /proc/mounts
over /etc/mtab to determine if a device is in-use, because the latter
can be incorrect after a crash, and the root filesystem is read-only at
this time.  There was recently a bug report about this from Slackware
users, where fsck is run on all of the filesystems before root is
remounted rw.  As a result, there is now even extra checking to see if
the devno of the mountpoint == devno of the device, otherwise it assumes
the /etc/mtab entry is bogus.

On most other systems, root is remounted rw before non-root filesystems
are checked, and /etc/mtab could be assumed to be correct, but it will
never be checked if /proc/mounts exists.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert