Jon Masters <[EMAIL PROTECTED]> wrote: > I think the shared superblock approach is the right one, but I'm a > little concerned that there would now be different behavior for fscache > and non-cached setups. Not sure of any better idea though.
The behaviour varies a bit anyway because there's a cache... > > The R/O mount flag can be dealt with by moving readonlyness into the > > vfsmount rather than having it a property of the superblock. The > > superblock would then be read-only only if all its vfsmounts are also > > read-only. > > Given that, how many connection parameters are there that are likely to > actually differ on the same client, talking to the same server? Really? I don't have figures on that, but I do know people have complained about it for non-cached conditions. > You could store the table in a NIS map, for example, and a udev rule or > similar could trigger to load it later. My point was meant to be that the presence and coverage of a cache is more likely to reflect the client machine than would the NIS map for the NFS automounts. You wouldn't necessarily want to store this table in NIS. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
