why reiserfs is so slow on deletion

[secondmouse]

The other day I had to do a deletion of squid-report files generated by sarg on a SuSE 10.2 with reiserfs as the partition file system, the folder is full of html files organized in sub-folders and the size is more than 20G, so I cd to
/path/to/the/squid-report/folder
and did a rm -rf *, I was expecting it to finish in minutes if not seconds. But it took more than 30 minutes for the task to complete. The computer is not slow at all. As a matter of fact, it's a Xeon 2.4GHZ with 4G RAM and a 7200RPM HD. Should the filesystem be the reason to blame for slowness in deletion?

[waterhead]

This is a complaint that I often see about the reiserfs. Most distros now use the ext3 file system by default. If you want a file system that can delete large file quickly, I suggest using the JFS or XFS file systems.

[secondmouse]

Interestingly I came across another Reiserfs related problem on another OpenSuSE 10.2 system. It has a 1TB HD with reiserfs as the file system (1 partition). I use it for email archives. Started days ago, the partition started to refuse write request. A simple unmount/(re)mount "fix" the problem (sometimes need to do a fsck.reiserfs before mounting) but came back again very quickly. Some error message in /var/log/messages

Sep 16 11:06:46 localhost kernel: SCSI device sdb: drive cache: write through
Sep 16 11:06:51 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Sep 16 11:06:51 localhost kernel: ata2.00: (BMDMA stat 0x4)
Sep 16 11:06:51 localhost kernel: ata2.00: cmd 35/00:00:57:db:8f/00:04:73:00:00/e0 tag 0 cdb 0x0 data 524288 out
Sep 16 11:06:51 localhost kernel: res 51/10:95:c2:dc:8f/00:00:00:00:00/e3 Emask 0x81 (invalid argument)
Sep 16 11:06:51 localhost kernel: sd 1:0:0:0: SCSI error: return code = 0x08000002
Sep 16 11:06:51 localhost kernel: sdb: Current: sense key: Aborted Command
Sep 16 11:06:51 localhost kernel: Additional sense: Recorded entity not found
Sep 16 11:06:51 localhost kernel: end_request: I/O error, dev sdb, sector 1938807639
Sep 16 11:06:51 localhost kernel: ata2: EH complete
Sep 16 11:06:52 localhost kernel: SCSI device sdb: 1953525168 512-byte hdwr sectors (1000205 MB)
Sep 16 11:06:52 localhost kernel: sdb: Write Protect is off
Sep 16 11:06:52 localhost kernel: sdb: Mode Sense: 00 3a 00 00
Sep 16 11:06:52 localhost kernel: SCSI device sdb: drive cache: write through
Sep 16 11:06:56 localhost kernel: REISERFS: abort (device sdb1): Journal write error in flush_commit_list
Sep 16 11:06:56 localhost kernel: REISERFS: Aborting journal for filesystem on sdb1
Sep 16 11:07:03 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Sep 16 11:07:03 localhost kernel: ata2.00: (BMDMA stat 0x4)
Sep 16 11:07:03 localhost kernel: ata2.00: cmd 35/00:98:7f:2a:9c/00:01:73:00:00/e0 tag 0 cdb 0x0 data 208896 out
Sep 16 11:07:03 localhost kernel: res 51/10:cd:4a:2b:9c/00:00:00:00:00/e3 Emask 0x81 (invalid argument)
Sep 16 11:07:03 localhost kernel: sd 1:0:0:0: SCSI error: return code = 0x08000002
Sep 16 11:07:03 localhost kernel: sdb: Current: sense key: Aborted Command
Sep 16 11:07:03 localhost kernel: Additional sense: Recorded entity not found
Sep 16 11:07:03 localhost kernel: end_request: I/O error, dev sdb, sector 1939614335
Sep 16 11:07:03 localhost kernel: ata2: EH complete
Sep 16 11:07:03 localhost kernel: SCSI device sdb: 1953525168 512-byte hdwr sectors (1000205 MB)
Sep 16 11:07:04 localhost kernel: sdb: Write Protect is off
Sep 16 11:07:04 localhost kernel: sdb: Mode Sense: 00 3a 00 00
Sep 16 11:07:04 localhost kernel: SCSI device sdb: drive cache: write through
Sep 16 11:07:08 localhost kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0

I did some googling but couldn't find a sounding solution. Eventually I made up my mind to reformat the partition with ext3 to see if it's a filesystem issue or a hardware problem. If it still has problem then I can conclude the drive needs to be replaced. (not likely because it's brand new)

I also made up my mind to use ext3 from now on as the default fs from now on because reiserfs has given me a number of hard-times include one that results in the loss of a folder with thousands of emails in it.

Hope this helps a bit when you have to decide which file system to use.

[HROAdmin26]

Sep 16 11:06:51 localhost kernel: ata2.00: cmd 35/00:00:57:db:8f/00:04:73:00:00/e0 tag 0 cdb 0x0 data 524288 out
Sep 16 11:06:51 localhost kernel: res 51/10:95:c2:dc:8f/00:00:00:00:00/e3 Emask 0x81 (invalid argument)
Sep 16 11:06:51 localhost kernel: sd 1:0:0:0: SCSI error: return code = 0x08000002
Sep 16 11:06:51 localhost kernel: sdb: Current: sense key: Aborted Command
Sep 16 11:06:51 localhost kernel: Additional sense: Recorded entity not found
Sep 16 11:06:51 localhost kernel: end_request: I/O error, dev sdb, sector 1938807639

This is a HW error - it comes from the kernel/SCSI code and has nothing to do with the filesystem. It even tells you what sector it was trying to access. Perhaps your slow deletes are related to the HDD error(s).

I've used reiserfs on production systems for many years now with less issues than I've seen with other filesystems. Ext3 is merely ext2 with a journal tacked on. I have had situations where the journal became corrupt, so the filesystem dropped it and continued running as ext2. Of course this only became known after a hard reboot where data was lost (because there was no journal.)

You can find many benchmarks on filesystems and ext3 is rarely the top performer. As always, it all depends on your system and your needs.

If your application primarily uses lots of smaller files, ReiserFS v3 is the way to go. If your application uses more medium to larger files, and not a whole lot of them, XFS would most likely be a wise choice.

This is what I have found to be true in my own usage/testing.

HTH.

[secondmouse]

Thanks HROAdmin26 for the info. Hope you don't mind but do you know any program/utility that can detect HD hardware problems?

[HROAdmin26]

Generally, the smartd daemon can monitor your drives if they are smart-enabled.

For example, my desktop system reports every time the drive temperature changes...

Sep 17 13:00:15 SYS syslog-ng[2370]: STATS: dropped 0
Sep 17 13:23:02 SYS smartd[3659]: Device: /dev/sda, SMART Usage Attribute: 194 Temperature_Celsius changed from 104 to 103
Sep 17 13:53:02 SYS smartd[3659]: Device: /dev/sdb, SMART Usage Attribute: 194 Temperature_Celsius changed from 108 to 107

[secondmouse]

I must have turned smartd off sometime in the past. Anyhow after I turned it back on and I saw lines like these in /var/log/messages:

Sep 17 19:09:53 localhost smartd[17371]: Device: /dev/sdb, 84 Currently unreadable (pending) sectors
Sep 17 19:09:53 localhost smartd[17371]: Sending warning via /usr/lib/smartmontools/smart-notify to root@localhost ...
Sep 17 19:09:53 localhost smartd[17371]: Warning via /usr/lib/smartmontools/smart-notify to root@localhost produced unexpected output (54 bytes) to STDOUT/STDERR: method return sender=:1.4 -> dest=:1.4209 uint16 0
Sep 17 19:09:53 localhost smartd[17371]: Warning via /usr/lib/smartmontools/smart-notify to root@localhost: successful
Sep 17 19:09:53 localhost smartd[17371]: Device: /dev/sdb, 83 Offline uncorrectable sectors
Sep 17 19:09:53 localhost smartd[17371]: Sending warning via /usr/lib/smartmontools/smart-notify to root@localhost ...
Sep 17 19:09:53 localhost smartd[17371]: Warning via /usr/lib/smartmontools/smart-notify to root@localhost produced unexpected output (54 bytes) to STDOUT/STDERR: method return sender=:1.4 -> dest=:1.4210 uint16 0
Sep 17 19:09:53 localhost smartd[17371]: Warning via /usr/lib/smartmontools/smart-notify to root@localhost: successful
Sep 17 19:09:54 localhost smartd[17381]: smartd has fork()ed into background mode. New PID=17381.


I think you are right about this HD. I should be thinking about changing it soon. Thanks again for your help.

[gogalthorp]

FYI- I use a commercial program called Spinrite to do low level scans. It is the most likely program to catch and correct hard disk problems. Note this is one that you run over night.

[waterhead]

FYI- I use a commercial program called Spinrite to do low level scans. It is the most likely program to catch and correct hard disk problems. Note this is one that you run over night.

I just tried Spinrite on a 120MB drive, it seems to have a corrupt MBR section. I opted for the advanced scan, and the time to completion was 5800 + hours! That's more than 241 days, so I canceled it.

I guess that I could try the less advanced scan.

[gogalthorp]

Hmm that is excessive but if it if there is a fault in the first few sectors then it is going to look like a long time to complete particularly if you have selected the deepest action. My 150 meg drive take about an hour and a half normally with no errors if there are errors then it can take 3-4 hours with medium correction. if the program has to try to correct every sector it is shot anyway.