Hi "W. Wilson Ho" wrote:
> Hi Lena, > > We finally got a programmable power supply and now the experiment > can be carried out more precisely. We cycle the power to the > machine every 8 minutes. Every time the machine boots up, it runs > a program that repeatedly generates lots of empty directory. Here > is what we found: > > With elevator turned on: 5 corruptions out of 16 runs. > With elelvator turned off: 4 corruptions out of 28 runs. > With both elevator and disk write cache turned off: 0 corruptions > out of 115 runs. > > We are still running a test with elevator turned on but disk write > cache turned off. It'll take another 12 hours. > It will be very interesting. > > You mentioned that the elevator algorithm should only affect > performance. Does it mean ReiserFS already handles the case where > disk blocks are written out-of-order? Yes. When reiserfs cares about order of write it makes a request to driver and waits on its completion. ll_rw_block (WRITE, 1, &bh); wait_on_buffer (bh); After that it thinks that data on buffer bh are hardened on disk. It is not true when write caching is on and if power goes off soon - some disks are not able to flush their cache down to media. I would call this not good hardware. But, IIRC, sometime ago there were a discussion about this issue and it was said there that this is intentional behaviour of disks. Unfortunately, I do not remember which argumets were used to explain that. > A quick scan of journal.c > seems to suggest that the journal blocks need to be flushed FIFO? > How does reiserfs detects corrupted or missing journal blocks > during replay (at mount time)? On mount time - it does not. It only looks for transactions which have to be replayed. > > > Also, here are some of the error messages when the file system is > corrupted: > > is_tree_node: node level 5019 does not match to the expected one > vs-5150: search_by_key: invalid format found in block 16379. Fsck? > reiserfs_read_inode2: i/o failure occurred trying to find stat > data of [9163 36747 0x0 SD] > is_leaf: free space seems wrong: level=1, nr_items=13, > free_space=65500 rdkey > zam-7001: io error in reiserfs_find_entry Later reiserfs notices corruption (not written metadata) when it is doing lookup through metadata. Thanks, vs
