On Fri, Jul 08, 2011 at 06:36:53PM +0100, Alan Brown wrote: > On Fri, 8 Jul 2011, Colin Simpson wrote: > > > That's not ideal either when Samba isn't too happy working over NFS, and > > that is not recommended by the Samba people as being a sensible config. > > I know but there's a real (and demonstrable) risk of data corruption for > NFS vs _anything_ if NFS clients and local processes (or clients of other > services such as a samba server) happen to grab the same file for writing > at the same time. With default mount options, the linux NFS client (like most NFS clients) assumes that a file has a most one writer at a time. (Applications that need to do write-sharing over NFS need to use file locking.) Note this issue isn't special to local process--the same restriction applies to two NFS clients writing to the same file. > Apart from that, the 1 second granularity of NFS timestamps The NFS protocol supports higher granularity timestamps. The limitation is the exported filesystem. If you're using something other than ext2/3, you're probably getting higher granularity. > can (and has) > result in writes made by non-nfs processes to cause NFS clients which have > that file opened read/write to see "stale filehandle" errors due to the > inode having changed when they weren't expecting it. Changing file data or attributes won't result in stale filehandle errors. (Bug reports welcome if you've seen otherwise.) Stale filehandle errors should only happen when a client attempts to use a file which no longer exists on the server. (E.g. if another client deletes a file while your client has it open.) (This can also happen if you rename a file across directories on a filesystem exported with the subtree_check option. The subtree_check option is deprecated, for that reason.) > We (should) all know NFS was a kludge. What's surprising is how much > kludge stll remains in the current v2/3 code (which is surprisingly opaque > and incredibly crufty, much of it dates from the early 1990s or earlier) Details welcome. > As I said earlier, V4 is supposed to play a lot nicer V4 has a number of improvements, but what I've described above applies across versions (module some technical details about timestamps vs. change attributes). --b. > but I haven't tested > it - as as far as I know it's not suported on GFS systems anyway (That was > the RH official line when I tried to get it working last time..) > > I'd love to get v4 running properly in active/active/active setup from > multiple GFS-mounted fileservers to the clients. If anyone knows how to > reliably do it on EL5.6 systems then I'm open to trying again as I believe > that this would solve a number of issues being seen locally (including > various crash bugs). > > On the other hand, v2/3 aren't going away anytime soon and some effort > really needs to be put into making them work properly. > > On the gripping hand, I'd also like to see viable alternatives to NFS when > it comes to feeding 100+ desktop clients > > Making them mount the filesystems using GFS might sound like an > alternative until you consider what happens if any of them crash/reboot > during the day. Batch processes can wait all day, but users with frozen > desktops get irate - quickly. > > > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
