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]
