From: braver@pobox.com
Date: 09/10/99-04:16:48 PM Z
From: braver@pobox.com Date: Fri, 10 Sep 1999 17:16:48 -0400 Message-Id: <199909102116.RAA01898@roll.setup.org> Subject: Re: fsync() fails under NFS, right? o This doesn't really have anything current to do with NFS Version 4, o but I thought that I would respond anyway. Well, I just discovered the list, but you guys discussed transactional enhancements to NFS. If you don't know whether something is on disk or not, how can any such transactionality be ensured?! My question is based on observing NFS behavior on Sun and Linux. On both, fsync() is misleading, using a presidential adjective. :-) o Several questions -- o o When you mentioned "superblock" are you refering to block on a UFS file o system which contains the file system configuration information and o such? If so, fsync(2) has nothing to do with that. I used an overloaded term, mea culpa. The superblock I'm talking about has nothing to do with an underlying system. It's a part of the user file implementing our transactional database. A "commit" is done by writing a certain sector-size block atomically into the file. For mental health of all those involved, it is vital that the fact of such write-through is known for sure. o The NFS protocol(s) don't know anything about fsync(2). It is up the o individual client implementation to support fsync(2) or not, depending o upon its own set of semantics. If your particular client doesn't o support fsync(2) correctly, then I would suggest complaining to the o vendor which supplied your NFS implementation. It is just a bug. o So, what is the platform which you are using? Linux and Sun both return success upon fsync()'ing an NFS-mounted, just created, 0-filled 100 Mb file in less time than it is physically possible. If this is a "client" bug, the clients take 95% of the NFS universe. I know you're working out the new specs, but something must be explicitly said about such blatant violation of intended semantics. Without atomicity and locking, already broken in existing NFS (i.e. "clients" covering 95% of the installations), a dysfunctional fsync() makes transactional databases' life horrific under Unix. They shouldn't be! o Thanx... o o ps -- Cheers, Alexy V. Khrabrov -- www.suffix.com -- Segmentation f%^*&
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:33 AM Z CST