>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]
