Re: ext3, BKL, journal replay, multiple non-bind mounts of same device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Apr 10, 2007  20:49 -0400, John Anthony Kazos Jr. wrote:
> Since it is possible for the same block device to be mounted multiple 
> times concurrently by the same filesystem, and since ext3 explicitly 
> disables the BKL during its fill_super operation which would prevent this, 
> what is the result of mounting it multiple times this way? Especially if 
> the filesystem is dirty and a journal is replayed. (In any case, what 
> operation is being performed by ext3/ext4 that requires the BKL to be 
> dropped? What's the need to even consider the BKL during fill_super?)
> 
> And in general, how does a filesystem deal with being mounted multiple 
> times in this way? In my testing and exploration so far, everything seems 
> to generally work, but I haven't tried deliberately using different 
> instances of the mount concurrently. Do we end up with locks not being 
> held properly on the superblock because the super_block structure 
> instances don't know about each other? Has dealing with this behavior of 
> bd_claim really been considered before, and if so, what's the general 
> scheme for handling it?

It is a myth (that actually frightened me quite a bit when I first did it)
that the filesystem is mounted twice in this case.  The truth of the matter
is if you "mount -t ext3 /dev/XXXX /mnt/1" and "... /mnt/2" you actually
get the equivalent of a bind mount for this block device on the two mount
points.  You can see this easily because e.g. you don't get two kjournald
threads for the two mounts, and it doesn't completely blow up.

If, on the other hand, you tried one mount with ext3 and another with ext4
it will fail the second with -EBUSY.

As for the BKL changes, your best bet is to go back through GIT and/or BK
or search the mailing lists to see when and why that was added.  It appears
to have  been 2.6.11, but I don't know why.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux