> > I haven't heard anything about the corruption on read-only file systems > > for quite some time. I think they were actually using dd as the example > > program for this. > at least the example I'm thinking of, talked about r-o fs corruption > because of some wierd case of cache corruption, because of dump. > was mentioned on lwn.net's kernel page, some months ago. ok, I found the reference. my apologies; it's not actually read-only filesystems that can be corrupted; it's just /filesystems that the dump process has no write access to/ and other processes do. http://lwn.net/2001/0503/kernel.php3 <<< *Trashing your filesystem with dump.* It has been known for a very long time that using dump to back up live filesystems can result in corrupt backups. It turns out that, with Linux kernels through 2.4.4, dumping a live filesystem has the potential to corrupt the filesystem in place, even if the dump process has no write access. Alexander Viro reported the bug which makes this possible. It can happen only on SMP systems, and is not easy to trigger, but it is there. Essentially, if the filesystem allocates a new metadata block for the filesystem, and a separate process reads that block at the wrong time, the wrong data will be written back to disk. The fix is relatively straightforward, and has already been incorporated into 2.4.5pre1. Linus pointed out an interesting little fact as part of this discussion: dump will not work correctly on 2.4-based systems in any case. The filesystem keeps quite a bit of useful information in the page cache - and will do so even more in the future. dump, however, works with the raw device, which deals with the buffer cache instead. The two are not always synchronized, and it is possible that dump will end up reading the wrong data. In case that's not clear enough: So anybody who depends on "dump" getting backups right is already playing russian rulette with their backups. It's not at all guaranteed to get the right results - you may end up having stale data in the buffer cache that ends up being "backed up". For now, there is really no easy way to fix dump for 2.4. If you're using it, this might be a good time to go looking for a different tool. >>> Carl Soderstrom -- Network Engineer Real-Time Enterprises (952) 943-8700