Re: mount -o remount problems with ext3 and journal= options in /etc/fstab

Re: mount -o remount problems with ext3 and journal= options in /etc/fstab

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1834 bytes --]

On Thursday 27 November 2008 18:02:27 Karel Zak wrote:
> On Thu, Nov 27, 2008 at 02:47:44PM -0500, Mike Frysinger wrote:
> > if you specify journal=update in /etc/fstab, then attempts to remount
> > that point can be a bit painful
> >
> > for example:
> > dd if=/dev/zero of=foo count=10000
> > mke2fs -F -j foo
> > mkdir foo-mount
> > echo $PWD/foo $PWD/foo-mount ext3 defaults,loop,journal=update >>
> > /etc/fstab mount foo-mount
> > mount foo-mount -o remount,ro
> >
> > the last command will result in:
> > mount: /root/foo-mount not mounted already, or bad option
>
>  this is a generic remount EINVAL error message
>
> > and the dmesg output will show us:
> > EXT3-fs: cannot specify journal on remount
> >
> > so should mount be handling this ?
>
>  How do you want to handle this in mount(8)? It's fs-depend option and
>  all is this behaviour is managed by kernel.

just fishing for ideas atm to see what others think

> > or should we update ext3 to only abort if the journal= option given
> > at remount is different from the initial mount ?
>
>  ... CC: linux-fs or linux-ext4 list ?

well, i guess the first question to ask is, does it make sense to have these 
journal options in /etc/fstab ?

handling journal=update is easy, but journal=inum and journal_dev= doesnt seem 
to be as easy since the value isnt retained afaict

--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -961,7 +961,7 @@ static int parse_options (char *options, struct 
super_block *sb,
 			   a journal file here.  For now, only allow the
 			   user to specify an existing inode to be the
 			   journal file. */
-			if (is_remount) {
+			if (is_remount && !test_opt(sb, UPDATE_JOURNAL)) {
 				printk(KERN_ERR "EXT3-fs: cannot specify "
 				       "journal on remount\n");
 				return 0;
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: mount -o remount problems with ext3 and journal= options in /etc/fstab

[Theodore Tso]

On Fri, Nov 28, 2008 at 05:03:10PM -0500, Mike Frysinger wrote:
> well, i guess the first question to ask is, does it make sense to have these 
> journal options in /etc/fstab ?

No, not really.  The original intent for journal=update was to update
from a V1 journal superblock to the V2 journal superblock.  This
transition happened in around 2001.  It was intended to be used to ask
the kernel to do a one-time conversion of the superblock version.
There's no real reason to have this in the kernel; it's the sort of
thing that is much better done in the userspace tools anyway. p

We should probably remove it from the kernel, actually.  There might
be some really ancient 2.4 systems that still have journals with V1
superblocks, but they are few and far between.

In any case, if this was going to be in the kernel, it makes
absolutely zero sense for it to be in /etc/fstab.  It should only be
something that the user manually specifies when first mounting the
filesystem, and for that reason it's actually better done in a
userspace tool.

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mount -o remount problems with ext3 and journal= options in /etc/fstab

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1211 bytes --]

On Saturday 29 November 2008 00:06:01 Theodore Tso wrote:
> On Fri, Nov 28, 2008 at 05:03:10PM -0500, Mike Frysinger wrote:
> > well, i guess the first question to ask is, does it make sense to have
> > these journal options in /etc/fstab ?
>
> No, not really.  The original intent for journal=update was to update
> from a V1 journal superblock to the V2 journal superblock.  This
> transition happened in around 2001.  It was intended to be used to ask
> the kernel to do a one-time conversion of the superblock version.
> There's no real reason to have this in the kernel; it's the sort of
> thing that is much better done in the userspace tools anyway. p
>
> We should probably remove it from the kernel, actually.  There might
> be some really ancient 2.4 systems that still have journals with V1
> superblocks, but they are few and far between.
>
> In any case, if this was going to be in the kernel, it makes
> absolutely zero sense for it to be in /etc/fstab.  It should only be
> something that the user manually specifies when first mounting the
> filesystem, and for that reason it's actually better done in a
> userspace tool.

sounds good.  i like rejecting bugs ;).  thanks for the summary.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 835 bytes --]