On Tue, 28 Aug 2007, David Olsen wrote:

>> On 27/08/2007, at 12:36 AM, Rainer J.H. Brandt wrote:
[ ... ]
>>> I don't see why multiple UFS mounts wouldn't work,
>> if only one
>>> of them has write access.  Can you elaborate?
>>
>> Even with a single writer you would need to be
>> concerned with read
>> cache invalidation on the read-only hosts and
>> (probably harder)
>> ensuring that read hosts don't rely on half-written
>> updates (since
>> UFS doesn't do atomic on-disk updates).

That synchronization issue is always there for shared filesystems. For 
example, the NFS specs mention it explicitly, sections 4.11 / 4.12 of RFC 
1813 for reference. Some quotes:

4.11 Caching policies

    The NFS version 3 protocol does not define a policy for
    caching on the client or server. In particular, there is no
    support for strict cache consistency between a client and
    server, nor between different clients. See [Kazar] for a
    discussion of the issues of cache synchronization and
    mechanisms in several distributed file systems.

4.12 Stable versus unstable writes
[ ... ]
    Unfortunately, client A can't tell for sure, so it will need
    to retransmit the buffers, thus overwriting the changes from
    client B.  Fortunately, write sharing is rare and the
    solution matches the current write sharing situation. Without
    using locking for synchronization, the behaviour will be
    indeterminate.

"Just sharing" a filesystem, even when using something "made to share" 
like NFS, doesn't solve writer/reader cache consistency issues. There 
needs to be a locking / arbitration mechanism (which in NFS is provided by 
rpc.lockd _AND_ the use of flock/fcntl in the applications - and which is 
done by a QFS-private lockmgr daemon for the "shared writer" case) if the 
shared resource isn't readonly-for-everyone.

As long as everyone is reader, or writes are extremely infrequent, 
"sharing" doesn't cause problems. But if that makes you decide to "simply 
share the SAN because it [seems to] works", think again. Sometimes, a 
little strategic planning is advisable.


FrankH.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to