[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 10/07/10 22:41, Simon Waters wrote: > 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. > > hmm inconsistent. Perhaps a trawl through the relevant kernel source might clarify the situation ;-) then again perhaps not ..... Or could it be that the kernel is expecting the HDD's internal firmware to correctly diagnose and report CRC errors block errors? In which case it could be firmware issues on the HDD. Tom. -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq