Flushing data to disk

[Jan Meijer]

L.S.

I am looking for a 100% guaranteed way to make sure that data that was written to a new file has actually landed on the disk (and is not still in buffercache). Will the sync command be sufficient?

This question is related to Business Copy volumes on our XP256 diskarray.
I have experienced problems with data from files on the primary BC-disk that seemed to be still in the buffercache. After splitting the pair the data was not (yet) available on the secondary disk.

[Edward Sedgemore]

You need to do 3 of them to be sure;

sync;sync;sync

[James R. Ferguson]

Hi:

Running 'sync' should flush all data from memory to disk. The man pages (1M) for 'sync' do note that "The writing, although scheduled, is not necessarily complete upon return from sync.". You might want to issue the 'sync' and then wait a short period before continuing.

...JRF...

[Jan Meijer]

Okay, sync seems to be the solution. But what if I want to sync just one particular (flag-)file?
Does anybody know what the -l option of sync means?

[James R. Ferguson]

Hi:

Interesting question. I hadn't noticed the '-l' option. The man pages for 10.20, 11.0 and 11.11 all show it but make no mention of its use. In fact, running 'sync' with any options seems to be ignored -- no complaint of mis-usage. I suspect that perhaps at one time there was an affect (?). I would use 'sync' alone.

...JRF...

[Dave Wherry]

sync will not do what you want to accomplish. sync is only going to flush the buffer cache on your host. It is true that the data will then be "off" the host. However, it is in cache on your XP and maybe not flushed to the disk. I have asked HP and been told there is no way to force a flush (sync) of the XP cache. It will do it on it's own sweet time according to it's cache aging process.
As far as the host is concerned the write is committed. It may not be to the disk yet. That is one of the reasons the cache on the XP has a 48 hour battery backup.

[Curt Thompson]

Hello Eisse van Hoving,

I can confirm what Dave has posted; the buffercache on the host is clear but the write is not committed to disk, especially with regards to the XP256. The XP256 is an array subsystem all its own and will de-stage the write to disk based on it own performance algorithms. Only when the XP256 is in a reduced state (some piece of redundant hardware has failed) will the array post all writes as a 'write-through cache' to both disk and cache, just in case.

Good Luck,
Curt

[Paul Spyrou]

Hi

Ensure that your filesystem is mounted with the convosync=direct paramter. You can add this to /etc/fstab
This will bypass buffer cache for writes and ensure that any data written will go to your frame. Once you split a volume with business copy the XP should d-stage it's cache and give you a consistent image.

[Ovidiu D. Raita]

Dave/Curt,

I don't think that the data that is still in XP's cache makes the BC inconsistent.

I don't imagine that HP/Hitachi would synch the BC disks disregarding the data stored in the cache.

The XP can store up to 32GB of data that can mess up all the BC file systems if disregarded.

It's true that an fsck is needed after you split the BC but that's needed only for the system's cache and not for XP's one.

If you wait at least 30 seconds for the sync to be perfomed you sould be safe and have an up-to-date BC.

For example, if you bring the system connected to the P-VOLs down and then split the BC you would NOT need to fsck the BC file systems before mounting them. This proves that the XP cached data is copied to the BC.

Ovidiu

[Rob Smith]

Hi, just as a matter of interest, a instructor at an HP class told me that a single sync command flushes 23% of buffer data to disk. So, based on that you actually have to do 5 syncs to ensure the data is written to disk. Has anyone elso ever heard this. Hope this helps.

Rob

[Lou Zirko_1]

Jan - Regarding the one file option you can write a small C program and use the system call fsync to accomplish this. This will not do anything about the XP's cache though. I really see no reason to write the program as the following would be just as effective.

sync; sync; sync

Doing it 3 times just allows for completion I think. Just an old habit with me.

Rob - Your instructor is 100% wrong. A single sync write "all" data. You just need to make sure you have allowed enough time for it to complete its task.

Lou Zirko

[Frank Slootweg]

Lou Zirko wrote:

> Rob - Your instructor is 100% wrong. A
> single sync write "all" data. You just need
> to make sure you have allowed enough time
> for it to complete its task.

That is true, but "enough time" can be a long time and it can be longer than the default syncer(1M) interval of 30 seconds. The reason for this is that if there are (too) many outstanding writes, syncer(1M) will not schedule all writes at once in order to try to limit the disk I/O peak.

The only reliable options are the (vxfs/JFS) mount options noted by Paul Spyrou and modifying the application(s) to use *SYNC (see for example "Synchronized I/O Flags" in open(2)).