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