Re: Appropriate use of sync() from user space?

From: Mark Mielke
Date: Tue Oct 18 2011 - 20:34:28 EST


On 10/18/2011 08:03 PM, david@xxxxxxx wrote:
On Tue, 18 Oct 2011, David Rientjes wrote:
On Tue, 18 Oct 2011, Jan Kara wrote:
Quick summary: We have a vendor who is claiming that it is required
for their userspace program to execute sync(), and I am looking for
some sort of authoritative document or person to refer them to that
will state that this belief is incorrect and/or that this
architecture is not acceptable in a Unix environment.

also, you may want to check if they are really doing a 'sync' (syncing the entire filesystem) or just a 'fsync' (syncing the file). Depending on the technical depth of the people you are talking to, they may say sync when what is actually happening is a fsync.

there is little dispute that fsync is correct, but not a complete answer to the issue. take a look at the LWN article on the subject at http://lwn.net/Articles/457667

Thanks, Dave. Yes, the vendor is doing a real sync() - and is also doing a few fsync(). We managed to convince them that this is a defect through their sales channel as technical failed. Oh well.

I note that you say "there is little dispute that fsync is correct ..." - which I also would have assumed, but I found very little authoritative documents on this. I think it is just so "self evident" (which the exception that you state in ext3) that people don't tend to do this.

In the mean time, our users are literally doing "sync; cleartool mkview ..." which forces most of the data out to disk before starting the vendor command, so that the IBM Rational "cleartool mkview" is able to complete successfully without timing out and failing after 3 to 5 minutes. *sigh*

The problematic file seems to be a VMware Player mmap()'d file with size of 1 GByte or more. ClearCase "cleartool mkview" vs VMware Player normal operation. *sigh x 2*

Thanks,
mark

--
Mark Mielke<mark@xxxxxxxxx>

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