Bug#355644: e2fsck needs to search for journal by UUID
On Sat, Mar 11, 2006 at 08:25:08PM -0800, Elliott Mitchell wrote: But those are unlikely to move around, and hence unlikely to change major number often. Devices that do move around are likely to carry their journal with them, so having the hint contain only the minor number would be sufficient. This could even be handled through a hook in hotplug. Nope. Consider the use case where the data filesystem is using a SCSI or a RAID disk, and the journal filesystem is using a battery-backed up memory disk which looks, feels, and smells like an IDE disk. In that case, the major number of the data partition != to the major number of the journal. So as you can see, just storing the minor number in the hint will not save you. Or consider the case where you are using SCSI id #5 for the data disk, but in order to get the faster performance, you have the external journal on a separate spindle, which is SCSI id #6. Now the system administrator does a clean shutdown of the system, and remove SCSI id #4. *Poof* the SCSI minor device id's get renumbered, so what used to be /dev/sdc1 and /dev/sdd1 now become /dev/sdb1 and /dev/sdc1, and any hints based on major/minor device numbers will be invalidated. If the system uses blkid to do mount-by-label, mount has no problem finding the data disk on /dev/sdb1, but the hint in the external journal is now incorrect. Since the entire system was cleanly shutdown, there is no reason why the system administrator needs to force an fsck just to update the hint; that's just inelegant. The solution is that the mount program needs to be able to use the blkid library to find the new location of the external journal as well. Nah, it's too hard, especially when you consider what might happen with iSCSI and Fibre Channel. Searching for filesystems by UUID really does belong in userspace. But mount does need to know how to specify the external journal to the filesystem, just as today it passes block device for the filesystem itself to the kernel. Strikes me as inelegant to not be able to directly call mount(). :-( You can't directly call mount if you are (a) mounting an NFS partition, without doing a lot of NFS-specific DNS name resolution, etc., or (b) if you are doing any kind of mount-by-label or mount-by-uuid. And this is because putting DNS resolution into the kernel, or doing find-block-device-by-UUID is insane. This is another example of needing to pass *all* of the parameters of the mount command into the kernel, and the location of the external journal is just one of the mount parameters, just as the IP address of the NFS server or where to find the data partition is one of the mount parameters. The hint was a convenience to system administrator for simple cases, but you can make the argument that we should have never implemented the hint, since it left us in a position where we didn't have all of the pieces (i.e., the journal_device mount option should have been implemented a long time ago), and got people lazy and complacent about finishing the userspace support for external journals. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355644: e2fsck needs to search for journal by UUID
On Fri, Mar 10, 2006 at 11:36:17PM -0800, Elliott Mitchell wrote:
In that situation mount has the UUID, and searches for a matching
filesystem. For this situation, it would have to look at the target
filesystem, and extract the journal UUID. That would require dwelving
fairly deeply into the filesystem. You're expecting libblkid to start
understanding filesystems? You planning to reimplement VFS in userspace?
(okay, perhaps not that deeply, but it is quite distinct from libblkid's
stated purpose)
Nope; it's *exactly* the same amount of work. In both cases, blkid
has to know where to find the superblock, and from there it can find
not only the filesystem UUID, and the filesystem label, but also the
journal UUID. To use C code, libblkid (and in mount's mount-by-label
code, which blkid obsoletes) we already have:
blkid_set_tag(dev, LABEL, es-s_volume_name,
sizeof(es-s_volume_name));
if (!uuid_is_null(es-s_uuid)) {
uuid_unparse(es-s_uuid, str);
blkid_set_tag(dev, UUID, str, sizeof(str));
}
What we are adding is:
if (!uuid_is_null(es-s_journal_uuid)) {
uuid_unparse(es-s_journal_uuid, str);
blkid_set_tag(dev, EXT_JOURNAL, str, sizeof(str));
}
This is not a lot of code, and it is a very small extension to what
the blkid library (or the mount program, if the blkid library is not
present) is doing already.
But if you know the filesystem is clean, why should you run e2fsck?
Just to set the superblock hint? That's broken, it should be
automatically done by mount. Anyway, that's the long-term direction
but it will requre getting the new blkid library functionality
released first, so I won't worry about it right away.
How much are block devices expected to change on every boot? For
automatically mounted filesystems, this could be done as part of
`fsck -a`. I'm unsure of the hint format, one solution would be to use 0
as a pseudo-major indicating to open the device of the same major but the
indicated minor. That would cover the common situation for removalable
storage that wasn't available at boot time. Know of anyone using external
journals on devices where the journal isn't on the same physical device?
I suspect not, as that really sounds like Russian Roulette.
It's not just block devices, it is major device numbering. There are
those who believe that major device numbers should not be stable, but
rather be arbitrarily assigned by module load time. That won't happen
in the 2.6 timeframe, but udev is certainly heading in that direction.
Furthermore, if you have block devices which are being found via
iSCSI, or Fibre channel, then there may be no such thing as a stable
load or probe order.
But yes, in some cases the journal may not be on the same physical
device; in fact, for best performance, it's best if the journal is
*not* on the same spindle as the data disk. That way, disk writes to
the journal are essentially sequential, whereas read/writes to the
data disk can and will be essentially random. In such a
configuration, doing data journally can actually be a huge speedup,
since you can simply write the blocks out to the journal essentially
in linear order.
Perhaps I was wrong earlier, it might in fact be best for the kernel to
know how to search for filesystems by UUID.
Nah, it's too hard, especially when you consider what might happen
with iSCSI and Fibre Channel. Searching for filesystems by UUID
really does belong in userspace. But mount does need to know how to
specify the external journal to the filesystem, just as today it
passes block device for the filesystem itself to the kernel.
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355644: e2fsck needs to search for journal by UUID
From: Theodore Ts'o [EMAIL PROTECTED] On Fri, Mar 10, 2006 at 11:36:17PM -0800, Elliott Mitchell wrote: How much are block devices expected to change on every boot? For automatically mounted filesystems, this could be done as part of `fsck -a`. I'm unsure of the hint format, one solution would be to use 0 as a pseudo-major indicating to open the device of the same major but the indicated minor. That would cover the common situation for removalable storage that wasn't available at boot time. Know of anyone using external journals on devices where the journal isn't on the same physical device? I suspect not, as that really sounds like Russian Roulette. It's not just block devices, it is major device numbering. There are those who believe that major device numbers should not be stable, but rather be arbitrarily assigned by module load time. That won't happen in the 2.6 timeframe, but udev is certainly heading in that direction. Furthermore, if you have block devices which are being found via iSCSI, or Fibre channel, then there may be no such thing as a stable load or probe order. You've got hardware where devices get assigned major and minor in random order? That seems rather odd. But yes, in some cases the journal may not be on the same physical device; in fact, for best performance, it's best if the journal is *not* on the same spindle as the data disk. That way, disk writes to the journal are essentially sequential, whereas read/writes to the data disk can and will be essentially random. In such a configuration, doing data journally can actually be a huge speedup, since you can simply write the blocks out to the journal essentially in linear order. But those are unlikely to move around, and hence unlikely to change major number often. Devices that do move around are likely to carry their journal with them, so having the hint contain only the minor number would be sufficient. This could even be handled through a hook in hotplug. Perhaps I was wrong earlier, it might in fact be best for the kernel to know how to search for filesystems by UUID. Nah, it's too hard, especially when you consider what might happen with iSCSI and Fibre Channel. Searching for filesystems by UUID really does belong in userspace. But mount does need to know how to specify the external journal to the filesystem, just as today it passes block device for the filesystem itself to the kernel. Strikes me as inelegant to not be able to directly call mount(). :-( -- (\___(\___(\__ --= 8-) EHM =-- __/)___/)___/) \BS (| [EMAIL PROTECTED] PGP 8881EF59 |) / \_CS\ | _ -O #include stddisclaimer.h O- _ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355644: e2fsck needs to search for journal by UUID
tags 355644 +pending
thanks
On Tue, Mar 07, 2006 at 06:12:25PM -0800, Elliott Mitchell wrote:
That isn't what I have a problem with in this case. Problem is `mount`
would have to understand the target filesystem in order to find out the
journal UUID is. `mount` doesn't have that sort of understanding of any
filesystem.
Actually mount does already, in order to support mount-by-label, but
what I would do is put that understanding into the blkid library,
which would is already being called by mount.
In the case of a read-only mount, sure. In the case of a read-write
mount, it already is required if the filesystem is unclean.
But if you know the filesystem is clean, why should you run e2fsck?
Just to set the superblock hint? That's broken, it should be
automatically done by mount. Anyway, that's the long-term direction
but it will requre getting the new blkid library functionality
released first, so I won't worry about it right away.
In any case, I've added the feature you requested, which is a
reasonable one; I just don't think it's an adequate solution by
itself.
- Ted
# HG changeset patch
# User [EMAIL PROTECTED]
# Node ID 75de1f7c349f4cd5938dccae7f196a3c2062e12f
# Parent 8634d28a8f278d91485c2dabb448188b586c9d01
Enhance e2fsck so it can fix external journal hint in the superblock
Check to see if the superblock hint for the external journal needs to
be updated, and if so, offer to update it. (Addresses Debian Bug:
#355644)
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
diff -r 8634d28a8f27 -r 75de1f7c349f e2fsck/ChangeLog
--- a/e2fsck/ChangeLog Wed Mar 8 18:25:30 2006 -0500
+++ b/e2fsck/ChangeLog Fri Mar 10 15:25:59 2006 -0500
@@ -1,3 +1,12 @@
+2006-03-10 Theodore Ts'o [EMAIL PROTECTED]
+
+ * e2fsck.h, journal.c (e2fsck_fix_ext3_journal_hint),
+ problem.c (PR_0_EXTERNAL_JOURNAL_HINT),
+ problem.h (PR_0_EXTERNAL_JOURNAL_HINT), super.c: Check
+ to see if the superblock hint for the external journal
+ needs to be updated, and if so, offer to update it.
+ (Addresses Debian Bug: #355644)
+
2006-01-29 Theodore Ts'o [EMAIL PROTECTED]
* unix.c (check_if_skip): When skipping a check due to being on
diff -r 8634d28a8f27 -r 75de1f7c349f e2fsck/e2fsck.h
--- a/e2fsck/e2fsck.h Wed Mar 8 18:25:30 2006 -0500
+++ b/e2fsck/e2fsck.h Fri Mar 10 15:25:59 2006 -0500
@@ -406,6 +406,7 @@
extern int e2fsck_check_ext3_journal(e2fsck_t ctx);
extern int e2fsck_run_ext3_journal(e2fsck_t ctx);
extern void e2fsck_move_ext3_journal(e2fsck_t ctx);
+extern int e2fsck_fix_ext3_journal_hint(e2fsck_t ctx);
/* pass1.c */
extern void e2fsck_use_inode_shortcuts(e2fsck_t ctx, int bool);
diff -r 8634d28a8f27 -r 75de1f7c349f e2fsck/journal.c
--- a/e2fsck/journal.c Wed Mar 8 18:25:30 2006 -0500
+++ b/e2fsck/journal.c Fri Mar 10 15:25:59 2006 -0500
@@ -959,3 +959,40 @@
return;
}
+/*
+ * This function makes sure the superblock hint for the external
+ * journal is correct.
+ */
+int e2fsck_fix_ext3_journal_hint(e2fsck_t ctx)
+{
+ struct ext2_super_block *sb = ctx-fs-super;
+ struct problem_context pctx;
+ char uuid[37], *journal_name;
+ struct stat st;
+ problem_t problem;
+ int retval;
+
+ if (!(sb-s_feature_compat EXT3_FEATURE_COMPAT_HAS_JOURNAL) ||
+ uuid_is_null(sb-s_journal_uuid))
+ return 0;
+
+ uuid_unparse(sb-s_journal_uuid, uuid);
+ journal_name = blkid_get_devname(ctx-blkid, UUID, uuid);
+ if (!journal_name)
+ return 0;
+
+ if (stat(journal_name, st) 0)
+ return 0;
+
+ if (st.st_rdev != sb-s_journal_dev) {
+ clear_problem_context(pctx);
+ pctx.num = st.st_rdev;
+ if (fix_problem(ctx, PR_0_EXTERNAL_JOURNAL_HINT, pctx)) {
+ sb-s_journal_dev = st.st_rdev;
+ ext2fs_mark_super_dirty(ctx-fs);
+ }
+ }
+
+ free(journal_name);
+ return 0;
+}
diff -r 8634d28a8f27 -r 75de1f7c349f e2fsck/problem.c
--- a/e2fsck/problem.c Wed Mar 8 18:25:30 2006 -0500
+++ b/e2fsck/problem.c Fri Mar 10 15:25:59 2006 -0500
@@ -341,6 +341,10 @@
{ PR_0_FUTURE_SB_LAST_WRITE,
N_(@S last write time is in the future. ),
PROMPT_FIX, PR_PREEN_OK },
+
+ { PR_0_EXTERNAL_JOURNAL_HINT,
+ N_(@S hint for external superblock @s %X. ),
+PROMPT_FIX, PR_PREEN_OK },
/* Pass 1 errors */
diff -r 8634d28a8f27 -r 75de1f7c349f e2fsck/problem.h
--- a/e2fsck/problem.h Wed Mar 8 18:25:30 2006 -0500
+++ b/e2fsck/problem.h Fri Mar 10 15:25:59 2006 -0500
@@ -189,6 +189,9 @@
/* Last write time is in the future */
#define PR_0_FUTURE_SB_LAST_WRITE 0x32
+
+/* Superblock hint for external journal incorrect */
+#define PR_0_EXTERNAL_JOURNAL_HINT 0x33
/*
* Pass 1
Bug#355644: e2fsck needs to search for journal by UUID
From: Theodore Ts'o [EMAIL PROTECTED] On Tue, Mar 07, 2006 at 06:12:25PM -0800, Elliott Mitchell wrote: That isn't what I have a problem with in this case. Problem is `mount` would have to understand the target filesystem in order to find out the journal UUID is. `mount` doesn't have that sort of understanding of any filesystem. Actually mount does already, in order to support mount-by-label, but what I would do is put that understanding into the blkid library, which would is already being called by mount. In that situation mount has the UUID, and searches for a matching filesystem. For this situation, it would have to look at the target filesystem, and extract the journal UUID. That would require dwelving fairly deeply into the filesystem. You're expecting libblkid to start understanding filesystems? You planning to reimplement VFS in userspace? (okay, perhaps not that deeply, but it is quite distinct from libblkid's stated purpose) In the case of a read-only mount, sure. In the case of a read-write mount, it already is required if the filesystem is unclean. But if you know the filesystem is clean, why should you run e2fsck? Just to set the superblock hint? That's broken, it should be automatically done by mount. Anyway, that's the long-term direction but it will requre getting the new blkid library functionality released first, so I won't worry about it right away. How much are block devices expected to change on every boot? For automatically mounted filesystems, this could be done as part of `fsck -a`. I'm unsure of the hint format, one solution would be to use 0 as a pseudo-major indicating to open the device of the same major but the indicated minor. That would cover the common situation for removalable storage that wasn't available at boot time. Know of anyone using external journals on devices where the journal isn't on the same physical device? I suspect not, as that really sounds like Russian Roulette. Perhaps I was wrong earlier, it might in fact be best for the kernel to know how to search for filesystems by UUID. -- (\___(\___(\__ --= 8-) EHM =-- __/)___/)___/) \BS (| [EMAIL PROTECTED] PGP 8881EF59 |) / \_CS\ | _ -O #include stddisclaimer.h O- _ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355644: e2fsck needs to search for journal by UUID
On Mon, Mar 06, 2006 at 09:44:47PM -0800, Elliott Mitchell wrote: I was in a hurry so I might of misread the symptoms I was seeing, but it sure looked like e2fsck 1.37-2sarge1 wasn't finding the journal. I didn't dare try reseting the field with tune2fs for fear of losing journal entries and data damage. I just built and tried e2fsprogs 1.37-2sarge1, with the external journal device original set up in /dev/loop0, and the filesystem in /dev/loop1, and then moving the journal device from /dev/loop0 to /dev/loop5, and indeed e2fsck was able to find it. You'll note that my first message said ...and correct the superblock field..., this is the main issue. Given that a filesystem with the journal device hint set wrong isn't mountable and tune2fs is dangerous on unclean filesystems, e2fsck MUST set the hint! Actually, it would be _nice_ if e2fsck set the hint, but it's not the only way to recover from the situation. You can also work around the problem by using the journal_dev mount option. For example, if the external journal device is now major 7, minor 5 (/dev/loop5, or 0x0705) and the filesystem is located at /dev/loop1, you can mount the filesystem using the command: mount -t ext3 -o journal_dev=0x0705 /dev/loop1 This will update the hint in the superblock. Isn't `mount` supposed to be a filesystem independant utility? At which point it has no business modifying flags in the superblock of an ext2 filesystem. No, it shouldn't be modifying flags in the superblock, but it should be checking to see if an external journal is required, and then specifying the journal_dev option if necessary. Mount does have some filesystem dependent code for various filesystems, in particular remote filesystems like nfs. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355644: e2fsck needs to search for journal by UUID
From: Theodore Ts'o [EMAIL PROTECTED] On Mon, Mar 06, 2006 at 09:44:47PM -0800, Elliott Mitchell wrote: I was in a hurry so I might of misread the symptoms I was seeing, but it sure looked like e2fsck 1.37-2sarge1 wasn't finding the journal. I didn't dare try reseting the field with tune2fs for fear of losing journal entries and data damage. I just built and tried e2fsprogs 1.37-2sarge1, with the external journal device original set up in /dev/loop0, and the filesystem in /dev/loop1, and then moving the journal device from /dev/loop0 to /dev/loop5, and indeed e2fsck was able to find it. Okay, may of been overly cautious here. Did you try using tune2fs to change the hint, and did it work? My concern is that the journal also has pointers back to the filesystem(s) it acts for, and those could be corrupted if tune2fs was unable to find the journal (at which point we're back to e2fsck correcting that). You'll note that my first message said ...and correct the superblock field..., this is the main issue. Given that a filesystem with the journal device hint set wrong isn't mountable and tune2fs is dangerous on unclean filesystems, e2fsck MUST set the hint! Actually, it would be _nice_ if e2fsck set the hint, but it's not the only way to recover from the situation. You can also work around the problem by using the journal_dev mount option. For example, if the external journal device is now major 7, minor 5 (/dev/loop5, or 0x0705) and the filesystem is located at /dev/loop1, you can mount the filesystem using the command: mount -t ext3 -o journal_dev=0x0705 /dev/loop1 This will update the hint in the superblock. Did you try that? Perhaps you're looking at a different kernel version, but in 2.6.14 no such option exists. I imagine the kernel folks would have the attitude of leaving this for userspace as it isn't the duty of the kernel to do such searches. This places the burdon on e2fsck, where I think it correctly belongs. Isn't `mount` supposed to be a filesystem independant utility? At which point it has no business modifying flags in the superblock of an ext2 filesystem. No, it shouldn't be modifying flags in the superblock, but it should be checking to see if an external journal is required, and then specifying the journal_dev option if necessary. Mount does have some filesystem dependent code for various filesystems, in particular remote filesystems like nfs. See above, no such option. To my knowledge none of that code actually touches the filesystem device, which would be required for mount to do such a thing. Either of these removes any such obligation. -- (\___(\___(\__ --= 8-) EHM =-- __/)___/)___/) \BS (| [EMAIL PROTECTED] PGP 8881EF59 |) / \_CS\ | _ -O #include stddisclaimer.h O- _ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355644: e2fsck needs to search for journal by UUID
On Tue, Mar 07, 2006 at 01:39:58PM -0800, Elliott Mitchell wrote:
I just built and tried e2fsprogs 1.37-2sarge1, with the external
journal device original set up in /dev/loop0, and the filesystem in
/dev/loop1, and then moving the journal device from /dev/loop0 to
/dev/loop5, and indeed e2fsck was able to find it.
Okay, may of been overly cautious here. Did you try using tune2fs to
change the hint, and did it work? My concern is that the journal also has
pointers back to the filesystem(s) it acts for, and those could be
corrupted if tune2fs was unable to find the journal (at which point we're
back to e2fsck correcting that).
No, I didn't use tune2fs to change the hint; it's not necessary.
E2fsck simply used the uuid in the filesystem to find the external
journal, using the blkid library. Tune2fs also uses the blkid library
to find the journal, so removing the journal and adding it back again
would have worked, but what I was interesting in disproving was your
contention that e2fsck can't find the journal. That's not true.
E2fsck finds the jouranl just fine. It just doesn't update the hint,
so that the in-kernel mount code can't find the journal.
In terms of external journal containing pointers back to the
filesystems, it does, but only via the filesystem UUID that it
supports, and so that works just fine.
mount -t ext3 -o journal_dev=0x0705 /dev/loop1
This will update the hint in the superblock.
Did you try that? Perhaps you're looking at a different kernel version,
but in 2.6.14 no such option exists. I imagine the kernel folks would
have the attitude of leaving this for userspace as it isn't the duty of
the kernel to do such searches. This places the burdon on e2fsck, where I
think it correctly belongs.
Yes, I did try it, and it did work. You're right that it is a
relatively new feature; it showed up in 2.6.16-rc1, and was committed
into the git tree on January 8, 2006. Ages ago as far as kernel
development is concerned! :-)
The attitude is indeed to leave this for userspace for doing such
searches; that's why what is specified is the device number. The
correct tool for doing the searches is the blkid library, which is
what e2fsck and tune2fs uses, and arguably mount should be enhanced to
use the blkid library as well for this case. Failing that, this tiny
bit of shell script would have done the trick for you (assuming you
were using a recent kernel, of course):
# Device to mount
DEV=/dev/loop1
UUID=`dumpe2fs $DEV 2/dev/null | awk '/^Journal UUID/{print $3}'`
JDEV=`blkid -t UUID=$UUID | awk -F: '{print $1}'`
DEVNUM=0x`stat -c %02t $JDEV``stat -c %02T $JDEV`
mount -o journal_dev=$DEVNUM $DEV
The problem with placing the burden solely on e2fsck is that if we
don't need to replay the journal (because the filesystem was unmounted
cleanly) e2fsck won't even attempt to find the journal, so it won't
know that the hint was incorrect. And what if e2fsck wasn't run for
some reason? The hint is never guaranteed to be correct, and in some
system setups might change at every boot. And requiring that e2fsck
be run before you can mount the filesystem is really broken.
Putting the burden on the userspace mount program is really the right
place from an architectural design point of view. Still, I'll add
something to e2fsck in the short term, since getting something into
will be slower, but it's really a short-term workaround and not the
right long-term solution.
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355644: e2fsck needs to search for journal by UUID
From: Theodore Ts'o [EMAIL PROTECTED] The attitude is indeed to leave this for userspace for doing such searches; that's why what is specified is the device number. The correct tool for doing the searches is the blkid library, which is what e2fsck and tune2fs uses, and arguably mount should be enhanced to use the blkid library as well for this case. Failing that, this tiny That isn't what I have a problem with in this case. Problem is `mount` would have to understand the target filesystem in order to find out the journal UUID is. `mount` doesn't have that sort of understanding of any filesystem. The extra understanding for NFS is for parameters in /etc/fstab or the command line, not knowledge of how the protocol itself works. Therefore I have to suggest it isn't fair to compare these. Perhaps if the kernel had a method to relay the UUID back to userspace mount could do it, but that doesn't seem too likely. The problem with placing the burden solely on e2fsck is that if we don't need to replay the journal (because the filesystem was unmounted cleanly) e2fsck won't even attempt to find the journal, so it won't know that the hint was incorrect. And what if e2fsck wasn't run for some reason? The hint is never guaranteed to be correct, and in some e2fsck inspects the superblock to determine whether the filesystem is clean or not. While it is looking there it would seem appropriate to run sanity checks on other fields as well. Failing that, adding an option to check that on an otherwise clean filesystem, and doing so by default when run interactively would seem appropriate. system setups might change at every boot. And requiring that e2fsck Sounds like I'm not the only Sadistic Sysadmin out here. be run before you can mount the filesystem is really broken. In the case of a read-only mount, sure. In the case of a read-write mount, it already is required if the filesystem is unclean. Putting the burden on the userspace mount program is really the right place from an architectural design point of view. Still, I'll add something to e2fsck in the short term, since getting something into will be slower, but it's really a short-term workaround and not the right long-term solution. Doesn't look that way to me. mount would have to understand the target filesystem in order to determine the journal UUID, and that seems to be too much for mount. -- (\___(\___(\__ --= 8-) EHM =-- __/)___/)___/) \BS (| [EMAIL PROTECTED] PGP 8881EF59 |) / \_CS\ | _ -O #include stddisclaimer.h O- _ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355644: e2fsck needs to search for journal by UUID
Package: e2fsprogs Version: 1.37-2sarge1 Severity: important Subject tells the story, because devics can change, e2fsck needs to be able to find external journal devices by UUID and correct the superblock field specifying the device. Isn't this why the journal UUID is present in the superblock? Luckily in my case I could rearrange things so the journal device reappeared with the old major/minor, remove it with tune2fs, move things back to their new setup and re-add the journal. For folks under pressure this would be quite problematic. Insisting on manual e2fsck to fix this error is certainly fair. With operator present e2fsck definitely needs to be able to do a UUID search. -- (\___(\___(\__ --= 8-) EHM =-- __/)___/)___/) \BS (| [EMAIL PROTECTED] PGP 8881EF59 |) / \_CS\ | _ -O #include stddisclaimer.h O- _ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355644: e2fsck needs to search for journal by UUID
On Mon, Mar 06, 2006 at 03:21:35PM -0800, Elliott Mitchell wrote: Package: e2fsprogs Version: 1.37-2sarge1 Severity: important Subject tells the story, because devics can change, e2fsck needs to be able to find external journal devices by UUID and correct the superblock field specifying the device. Isn't this why the journal UUID is present in the superblock? Um, e2fsck does search for the external journal device by UUID. It only falls back to the superblock field specifying the device if the journal can't be found. I think the problem you may be seeing is that it currently doesn't correct the superblock field specifying the device. E2fsck can find the journal, and it will replay the external journal if necessary. But at the moment it doesn't set the superblock hint. The hint by the way was always intended to be just that. Userspace can just as easily find the device using the blkid progam and pass it as a mount option. That's actually better because right now, if the the journal doesn't need to be replayed, we won't try to find the external journal, and so the hint won't necessarily be reset every single time --- and the device number can potentially shift between boots that don't require a journal replay. Still, it would probably be a good idea for e2fsck to set the superblock hint, even if the mount program should also be doing this as well. - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355644: e2fsck needs to search for journal by UUID
From: Theodore Ts'o [EMAIL PROTECTED] Um, e2fsck does search for the external journal device by UUID. It only falls back to the superblock field specifying the device if the journal can't be found. I was in a hurry so I might of misread the symptoms I was seeing, but it sure looked like e2fsck 1.37-2sarge1 wasn't finding the journal. I didn't dare try reseting the field with tune2fs for fear of losing journal entries and data damage. I think the problem you may be seeing is that it currently doesn't correct the superblock field specifying the device. E2fsck can find the journal, and it will replay the external journal if necessary. But at the moment it doesn't set the superblock hint. You'll note that my first message said ...and correct the superblock field..., this is the main issue. Given that a filesystem with the journal device hint set wrong isn't mountable and tune2fs is dangerous on unclean filesystems, e2fsck MUST set the hint! Still, it would probably be a good idea for e2fsck to set the superblock hint, even if the mount program should also be doing this as well. Isn't `mount` supposed to be a filesystem independant utility? At which point it has no business modifying flags in the superblock of an ext2 filesystem. -- (\___(\___(\__ --= 8-) EHM =-- __/)___/)___/) \BS (| [EMAIL PROTECTED] PGP 8881EF59 |) / \_CS\ | _ -O #include stddisclaimer.h O- _ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
