[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
tom brough wrote: > On 10/07/10 21:01, Simon Waters wrote: >> Curiosity driven question. >> >> If I write data to my external hard disk, how can I ensure that a read >> to verify that data isn't using a cache? >> > sync ? Or am I missing the point. I don't know that is why I asked. As far as I know "sync" only forces the buffer cache to be written to the disk device, it doesn't ensure the data is on disk just that it was requested to be written and the disk agreed. If the disk has write back caching it is in cache, if it is write-through cache the disk should have attempted to write it to disk. I found some comment that sync behaviour is filesystem dependent with XFS and Reiser doing the right thing - but "the right thing" wasn't spelt out in enough details for me to comment further. Certainly most disk technologies have a low level SYNC call, that allows the disk drive to write outstanding data to disk and report that back, but it isn't clear to me that the Linux system call "sync" always causes low level sync commands to be sent (it certainly didn't in the distant past). > When you do a sync; the buffers get forced out to disk, as an integrity > check the block written is re-read and the CRC header on the block is > checked (is this not why writes take longer than reads). Where is that integrity check documented? Most disks do an internal CRC check on each block, so they recognise if they read duff data, but they only do that on reading a fresh block from the platter. Most file systems have some sort of block CRC - so they can spot their own corruption either on disk or in memory. Just I've seen some behaviour recently suggesting that a check is done, and some suggesting a check isn't done. i.e. Read errors after writing to a bad block, and no error on writing to a bad block. -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq