Re: [patch 01/26] mount options: add documentation

[Miklos Szeredi]

> > > Could also please explain why you want to go via user
> > > mounts. Other OS use a daemon for that, which e.g. can maintain
> > > access controls. How do you want to manage this?
> > 
> > The unprivileged mounts patches do contain a simple form of access
> > control.  I don't think anything more is needed, but of course, having
> > unprivileged mounts in the kernel does not prevent the use of a more
> > sophisticated access control daemon in userspace, if that becomes
> > necessary.
> 
> A "I don't think anything more is needed" lets go off all sorts of warning 
> lights. Most things start out simple, so IMO it's very worth it to check 
> where it might go to to know the limits beforehand. The main question here 
> is why should a kernel based solution be preferable over a daemon based 
> solution?

A daemon based solution would work for the "normal" case, where we
have a single mount namespace and a single /etc/mtab file, and we hope
it doesn't get too much out of sync with what is actually in the
kernel (on remount the mount options do get out of sync, but hey, we
seem to be able to live with that).

However, once you start using multiple namespaces, the daemon based
solution quickly becomes unusable, because you would need a separate
daemon for each namespace, and it would have to somehow keep track of
mount propagations in userspace (which is basically impossible), etc,
etc...

Does that answer your question?

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Roman Zippel]

Hi,

On Wed, 30 Jan 2008, Miklos Szeredi wrote:

> > How does this deal with certain special cases:
> > - chroot: how will mount/df only show the for chroot relevant mounts?
> 
> That is a very good question.  Andreas Gruenbacher had some patches
> for fixing behavior of /proc/mounts under a chroot, but people are
> paranoid about userspace ABI changes (unwarranted in this case, IMO).
> 
>   http://lkml.org/lkml/2007/4/20/147
> 
> Anyway, if we are going to have a new 'mountinfo' file, this could be
> easily fixed as well.
> 
> > - loop: how is the connection between file and loop device maintained?
> 
> We also discussed this with Karel, maybe it didn't make it onto lkml.
> 
> The proposed solution was to store the "loop" flag separately in a
> file under /var.  It could just be an empty file for each such loop
> device:
> 
>   /var/lib/mount/loops/loop0
> 
> This file is created by mount(8) if the '-oloop' option is given.  And
> umount(8) automatically tears down the loop device if it finds this
> file.

My question was maybe a little short. I don't doubt that we can shove a 
lot into the kernel, the question is rather how much of this will be 
unnecessary information, which the kernel doesn't really need itself.

> > Could also please explain why you want to go via user mounts. Other OS use 
> > a 
> > daemon for that, which e.g. can maintain access controls. How do you want 
> > to 
> > manage this?
> 
> The unprivileged mounts patches do contain a simple form of access
> control.  I don't think anything more is needed, but of course, having
> unprivileged mounts in the kernel does not prevent the use of a more
> sophisticated access control daemon in userspace, if that becomes
> necessary.

A "I don't think anything more is needed" lets go off all sorts of warning 
lights. Most things start out simple, so IMO it's very worth it to check 
where it might go to to know the limits beforehand. The main question here 
is why should a kernel based solution be preferable over a daemon based 
solution?

If we look for example look at OS X, it has no need for user mounts but 
has a daemon instead, which also provides an interesting notification 
system for new devices, mounts or unmount requests. All this could also be 
done in the kernel, but where would be the advantage in doing so? The 
kernel implementation would be either rather limited or only bloat the 
kernel. What is the feature that would make user mounts more than just a 
cool kernel hack?

bye, Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Miklos Szeredi]

   Could also please explain why you want to go via user
   mounts. Other OS use a daemon for that, which e.g. can maintain
   access controls. How do you want to manage this?
  
  The unprivileged mounts patches do contain a simple form of access
  control.  I don't think anything more is needed, but of course, having
  unprivileged mounts in the kernel does not prevent the use of a more
  sophisticated access control daemon in userspace, if that becomes
  necessary.
 
 A I don't think anything more is needed lets go off all sorts of warning 
 lights. Most things start out simple, so IMO it's very worth it to check 
 where it might go to to know the limits beforehand. The main question here 
 is why should a kernel based solution be preferable over a daemon based 
 solution?

A daemon based solution would work for the normal case, where we
have a single mount namespace and a single /etc/mtab file, and we hope
it doesn't get too much out of sync with what is actually in the
kernel (on remount the mount options do get out of sync, but hey, we
seem to be able to live with that).

However, once you start using multiple namespaces, the daemon based
solution quickly becomes unusable, because you would need a separate
daemon for each namespace, and it would have to somehow keep track of
mount propagations in userspace (which is basically impossible), etc,
etc...

Does that answer your question?

Thanks,
Miklos
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Miklos Szeredi]

> > > - loop: how is the connection between file and loop device maintained?
> > 
> > We also discussed this with Karel, maybe it didn't make it onto lkml.
> > 
> > The proposed solution was to store the "loop" flag separately in a
> > file under /var.  It could just be an empty file for each such loop
> > device:
> > 
> >   /var/lib/mount/loops/loop0
> > 
> > This file is created by mount(8) if the '-oloop' option is given.  And
> > umount(8) automatically tears down the loop device if it finds this
> > file.
> 
>  It seems we needn't this solution. There is loop auto-destruction
>  patch in -mm.
> 
>  Kernel part:
> http://marc.info/?l=linux-kernel=119361296818388=2
> 
>  mount(8) part:
> http://marc.info/?l=util-linux-ng=119362955431694=2
> 
>  So, with this patch mount(8) needn't to maintain info about loops and
>  umount(8) doesn't need to call LOOP_CLR_FD ioctl, because umount(2)
>  is enough.

Excellent!  This is a very good example how moving a functionality
into the kernel can greatly simplify it.

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Miklos Szeredi]

   - loop: how is the connection between file and loop device maintained?
  
  We also discussed this with Karel, maybe it didn't make it onto lkml.
  
  The proposed solution was to store the loop flag separately in a
  file under /var.  It could just be an empty file for each such loop
  device:
  
/var/lib/mount/loops/loop0
  
  This file is created by mount(8) if the '-oloop' option is given.  And
  umount(8) automatically tears down the loop device if it finds this
  file.
 
  It seems we needn't this solution. There is loop auto-destruction
  patch in -mm.
 
  Kernel part:
 http://marc.info/?l=linux-kernelm=119361296818388w=2
 
  mount(8) part:
 http://marc.info/?l=util-linux-ngm=119362955431694w=2
 
  So, with this patch mount(8) needn't to maintain info about loops and
  umount(8) doesn't need to call LOOP_CLR_FD ioctl, because umount(2)
  is enough.

Excellent!  This is a very good example how moving a functionality
into the kernel can greatly simplify it.

Thanks,
Miklos
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Karel Zak]

On Wed, Jan 30, 2008 at 10:09:03AM +0100, Miklos Szeredi wrote:
> > - loop: how is the connection between file and loop device maintained?
> 
> We also discussed this with Karel, maybe it didn't make it onto lkml.
> 
> The proposed solution was to store the "loop" flag separately in a
> file under /var.  It could just be an empty file for each such loop
> device:
> 
>   /var/lib/mount/loops/loop0
> 
> This file is created by mount(8) if the '-oloop' option is given.  And
> umount(8) automatically tears down the loop device if it finds this
> file.

 It seems we needn't this solution. There is loop auto-destruction
 patch in -mm.

 Kernel part:
http://marc.info/?l=linux-kernel=119361296818388=2

 mount(8) part:
http://marc.info/?l=util-linux-ng=119362955431694=2

 So, with this patch mount(8) needn't to maintain info about loops and
 umount(8) doesn't need to call LOOP_CLR_FD ioctl, because umount(2)
 is enough.

Karel

-- 
 Karel Zak  <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Miklos Szeredi]

> > Q: Why do we need correct option showing in /proc/mounts?
> > A: We want /proc/mounts to fully replace /etc/mtab.  The reasons for
> >this are:
> > - unprivileged mounters won't be able to update /etc/mtab
> > - /etc/mtab doesn't work with private mount namespaces
> > - /etc/mtab can become out-of-sync with reality
> 
> I asked this before and I don't remember getting an answer:
> How does this deal with certain special cases:
> - chroot: how will mount/df only show the for chroot relevant mounts?

That is a very good question.  Andreas Gruenbacher had some patches
for fixing behavior of /proc/mounts under a chroot, but people are
paranoid about userspace ABI changes (unwarranted in this case, IMO).

  http://lkml.org/lkml/2007/4/20/147

Anyway, if we are going to have a new 'mountinfo' file, this could be
easily fixed as well.

> - loop: how is the connection between file and loop device maintained?

We also discussed this with Karel, maybe it didn't make it onto lkml.

The proposed solution was to store the "loop" flag separately in a
file under /var.  It could just be an empty file for each such loop
device:

  /var/lib/mount/loops/loop0

This file is created by mount(8) if the '-oloop' option is given.  And
umount(8) automatically tears down the loop device if it finds this
file.

> I don't quite see how you want to achieve a _full_ replacement.

I think a full replacement is perfectly feasible, just needs some more
work on the userspace side.

> Could also please explain why you want to go via user mounts. Other OS use a 
> daemon for that, which e.g. can maintain access controls. How do you want to 
> manage this?

The unprivileged mounts patches do contain a simple form of access
control.  I don't think anything more is needed, but of course, having
unprivileged mounts in the kernel does not prevent the use of a more
sophisticated access control daemon in userspace, if that becomes
necessary.

Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Miklos Szeredi]

  Q: Why do we need correct option showing in /proc/mounts?
  A: We want /proc/mounts to fully replace /etc/mtab.  The reasons for
 this are:
  - unprivileged mounters won't be able to update /etc/mtab
  - /etc/mtab doesn't work with private mount namespaces
  - /etc/mtab can become out-of-sync with reality
 
 I asked this before and I don't remember getting an answer:
 How does this deal with certain special cases:
 - chroot: how will mount/df only show the for chroot relevant mounts?

That is a very good question.  Andreas Gruenbacher had some patches
for fixing behavior of /proc/mounts under a chroot, but people are
paranoid about userspace ABI changes (unwarranted in this case, IMO).

  http://lkml.org/lkml/2007/4/20/147

Anyway, if we are going to have a new 'mountinfo' file, this could be
easily fixed as well.

 - loop: how is the connection between file and loop device maintained?

We also discussed this with Karel, maybe it didn't make it onto lkml.

The proposed solution was to store the loop flag separately in a
file under /var.  It could just be an empty file for each such loop
device:

  /var/lib/mount/loops/loop0

This file is created by mount(8) if the '-oloop' option is given.  And
umount(8) automatically tears down the loop device if it finds this
file.

 I don't quite see how you want to achieve a _full_ replacement.

I think a full replacement is perfectly feasible, just needs some more
work on the userspace side.

 Could also please explain why you want to go via user mounts. Other OS use a 
 daemon for that, which e.g. can maintain access controls. How do you want to 
 manage this?

The unprivileged mounts patches do contain a simple form of access
control.  I don't think anything more is needed, but of course, having
unprivileged mounts in the kernel does not prevent the use of a more
sophisticated access control daemon in userspace, if that becomes
necessary.

Miklos
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Karel Zak]

On Wed, Jan 30, 2008 at 10:09:03AM +0100, Miklos Szeredi wrote:
  - loop: how is the connection between file and loop device maintained?
 
 We also discussed this with Karel, maybe it didn't make it onto lkml.
 
 The proposed solution was to store the loop flag separately in a
 file under /var.  It could just be an empty file for each such loop
 device:
 
   /var/lib/mount/loops/loop0
 
 This file is created by mount(8) if the '-oloop' option is given.  And
 umount(8) automatically tears down the loop device if it finds this
 file.

 It seems we needn't this solution. There is loop auto-destruction
 patch in -mm.

 Kernel part:
http://marc.info/?l=linux-kernelm=119361296818388w=2

 mount(8) part:
http://marc.info/?l=util-linux-ngm=119362955431694w=2

 So, with this patch mount(8) needn't to maintain info about loops and
 umount(8) doesn't need to call LOOP_CLR_FD ioctl, because umount(2)
 is enough.

Karel

-- 
 Karel Zak  [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Roman Zippel]

Hi,

On Thursday 24. January 2008, Miklos Szeredi wrote:

> Q: Why do we need correct option showing in /proc/mounts?
> A: We want /proc/mounts to fully replace /etc/mtab.  The reasons for
>this are:
> - unprivileged mounters won't be able to update /etc/mtab
> - /etc/mtab doesn't work with private mount namespaces
> - /etc/mtab can become out-of-sync with reality

I asked this before and I don't remember getting an answer:
How does this deal with certain special cases:
- chroot: how will mount/df only show the for chroot relevant mounts?
- loop: how is the connection between file and loop device maintained?

I don't quite see how you want to achieve a _full_ replacement.

Could also please explain why you want to go via user mounts. Other OS use a 
daemon for that, which e.g. can maintain access controls. How do you want to 
manage this?

bye, Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Roman Zippel]

Hi,

On Thursday 24. January 2008, Miklos Szeredi wrote:

 Q: Why do we need correct option showing in /proc/mounts?
 A: We want /proc/mounts to fully replace /etc/mtab.  The reasons for
this are:
 - unprivileged mounters won't be able to update /etc/mtab
 - /etc/mtab doesn't work with private mount namespaces
 - /etc/mtab can become out-of-sync with reality

I asked this before and I don't remember getting an answer:
How does this deal with certain special cases:
- chroot: how will mount/df only show the for chroot relevant mounts?
- loop: how is the connection between file and loop device maintained?

I don't quite see how you want to achieve a _full_ replacement.

Could also please explain why you want to go via user mounts. Other OS use a 
daemon for that, which e.g. can maintain access controls. How do you want to 
manage this?

bye, Roman
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Miklos Szeredi]

> Where did you check for the existence of a ->show_options method for
> unionfs?  Unionfs does implement ->show_options and supports all of the
> mount/remount options.  See:
> 
> 
> 
> The unionfs ->remount code supports branch-management options which can
> add/del/change a branch, but we don't show those directly in ->show_options;
> it makes more sense to show the final (and thus most current) branch
> configuration.
> 
> Could you update your records please?

Sure.  Sorry about that, I did actually look at unionfs, and it was
just an administration error and bad memory (in my head).

> BTW, I should be able to use your save_mount_options().

It is probably better not to use save_mount_options().  Especially,
since unionfs implemets a remount, that changes the tree only
partially AFAICS.

Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[David Chinner]

> In message <[EMAIL PROTECTED]>, Miklos Szeredi writes:
> > From: Miklos Szeredi <[EMAIL PROTECTED]>
> > 
> > This series addresses the problem of showing mount options in
> > /proc/mounts.
[...]
> > The following filesystems still need fixing: CIFS, NFS, XFS, Unionfs,
> > Reiser4.  For CIFS, NFS and XFS I wasn't able to understand how some
> > of the options are used.  The last two are not yet in mainline, so I
> > leave fixing those to their respective maintainers out of pure
> > laziness.

XFS has already been updated. The fix is in the XFs git tree that
Andrew picks up for -mm releases and will be merged in the 2.6.25-rc1
window. Commit is here:

http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commit;h=8c33fb6ca99aa17373bd3d5a507ac0eaefb7abb4

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[David Chinner]

 In message [EMAIL PROTECTED], Miklos Szeredi writes:
  From: Miklos Szeredi [EMAIL PROTECTED]
  
  This series addresses the problem of showing mount options in
  /proc/mounts.
[...]
  The following filesystems still need fixing: CIFS, NFS, XFS, Unionfs,
  Reiser4.  For CIFS, NFS and XFS I wasn't able to understand how some
  of the options are used.  The last two are not yet in mainline, so I
  leave fixing those to their respective maintainers out of pure
  laziness.

XFS has already been updated. The fix is in the XFs git tree that
Andrew picks up for -mm releases and will be merged in the 2.6.25-rc1
window. Commit is here:

http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commit;h=8c33fb6ca99aa17373bd3d5a507ac0eaefb7abb4

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Miklos Szeredi]

 Where did you check for the existence of a -show_options method for
 unionfs?  Unionfs does implement -show_options and supports all of the
 mount/remount options.  See:
 
 http://git.kernel.org/?p=linux/kernel/git/ezk/unionfs.git;a=blob;f=fs/unionfs/super.c;h=986c980261a5b171147d66ac05bf08423e2fd6b6;hb=HEAD#l963
 
 The unionfs -remount code supports branch-management options which can
 add/del/change a branch, but we don't show those directly in -show_options;
 it makes more sense to show the final (and thus most current) branch
 configuration.
 
 Could you update your records please?

Sure.  Sorry about that, I did actually look at unionfs, and it was
just an administration error and bad memory (in my head).

 BTW, I should be able to use your save_mount_options().

It is probably better not to use save_mount_options().  Especially,
since unionfs implemets a remount, that changes the tree only
partially AFAICS.

Miklos
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Erez Zadok]

In message <[EMAIL PROTECTED]>, Miklos Szeredi writes:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
> 
> This series addresses the problem of showing mount options in
> /proc/mounts.
> 
> Several filesystems which use mount options, have not implemented a
> .show_options superblock operation.  Several others have implemented
> this callback, but have not kept it fully up to date with the parsed
> options.
[...]

> The following filesystems still need fixing: CIFS, NFS, XFS, Unionfs,
> Reiser4.  For CIFS, NFS and XFS I wasn't able to understand how some
> of the options are used.  The last two are not yet in mainline, so I
> leave fixing those to their respective maintainers out of pure
> laziness.
> 
> Table displaying status of all in-kernel filesystems:
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> legend:
> 
>   none - fs has options, but doesn't define ->show_options()
>   some - fs defines ->show_options(), but some only options are shown
>   most - fs defines ->show_options(), and shows most of them
>   good - fs shows all options
>   noopt - fs does not have options
>   patch - a patch will be posted
[...]

> in -mm:
> 
> reiser4 some
> unionfs none

Hi Miklos,

Where did you check for the existence of a ->show_options method for
unionfs?  Unionfs does implement ->show_options and supports all of the
mount/remount options.  See:



The unionfs ->remount code supports branch-management options which can
add/del/change a branch, but we don't show those directly in ->show_options;
it makes more sense to show the final (and thus most current) branch
configuration.

Could you update your records please?

BTW, I should be able to use your save_mount_options().

Cheers,
Erez.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 01/26] mount options: add documentation

[Erez Zadok]

In message [EMAIL PROTECTED], Miklos Szeredi writes:
 From: Miklos Szeredi [EMAIL PROTECTED]
 
 This series addresses the problem of showing mount options in
 /proc/mounts.
 
 Several filesystems which use mount options, have not implemented a
 .show_options superblock operation.  Several others have implemented
 this callback, but have not kept it fully up to date with the parsed
 options.
[...]

 The following filesystems still need fixing: CIFS, NFS, XFS, Unionfs,
 Reiser4.  For CIFS, NFS and XFS I wasn't able to understand how some
 of the options are used.  The last two are not yet in mainline, so I
 leave fixing those to their respective maintainers out of pure
 laziness.
 
 Table displaying status of all in-kernel filesystems:
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 legend:
 
   none - fs has options, but doesn't define -show_options()
   some - fs defines -show_options(), but some only options are shown
   most - fs defines -show_options(), and shows most of them
   good - fs shows all options
   noopt - fs does not have options
   patch - a patch will be posted
[...]

 in -mm:
 
 reiser4 some
 unionfs none

Hi Miklos,

Where did you check for the existence of a -show_options method for
unionfs?  Unionfs does implement -show_options and supports all of the
mount/remount options.  See:

http://git.kernel.org/?p=linux/kernel/git/ezk/unionfs.git;a=blob;f=fs/unionfs/super.c;h=986c980261a5b171147d66ac05bf08423e2fd6b6;hb=HEAD#l963

The unionfs -remount code supports branch-management options which can
add/del/change a branch, but we don't show those directly in -show_options;
it makes more sense to show the final (and thus most current) branch
configuration.

Could you update your records please?

BTW, I should be able to use your save_mount_options().

Cheers,
Erez.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/