# Is my hard drive on the way out?[SOLVED]-yes

## pteppic

```
/usr/include/nspr/nspr.h:45:20: error: /usr/include/nspr/prcvar.h: Input/output error
```

When an ebuild fails I genrally try to work out if there is anything I can do about it, and I can easily fix this, but 'Input/output error' has me worried a  bit. It's the second time I've seen the error, first time was in reference to a .ebuild file a couple of days ago.

I also think it may, instead, have something to do with the recent 'restore from .tar' to a new root partition (which would be better than a dieing drive), as the ebuild was 'out of date' and wouldn't have been re-written by --sync AFAIK.

Help in the best way to check the drive throughly would be appreciated, and if anyone can give other reasons for/insight into this error.

TIALast edited by pteppic on Tue Nov 21, 2006 7:37 pm; edited 1 time in total

----------

## nixnut

try looking for bad blocks with fsck.ext3 -c /dev/hdaX (assuming X is a ext2 or ext3 partition)

----------

## pteppic

Sorry, should have said, reiserfs3.

Will try fsck.reiserfs though...

EDIT: Ok, ran it, logged the output to a usb stick. It got this far

```
bad_indirect_item: block 666566: The item [103236 118023 0x83001 IND (1)] has the bad pointer (81) to the block (19)

bad_indirect_item: block 666566: The item [103236 118023 0x83001 IND (1)] has the bad pointer (83) to the block (3050263064)

..snip 60 odd lines...

bad_indirect_item: block 666566: The item [103236 118024 0x1 IND (1)] has the bad pointer (12) to the block (3034483456)

bad_indirect_item: block 666566: The item [103236 118024 0x1 IND (1)] has the bad pointer (13) to the block (42)

bad_indirect_item: block 666566: The item [103236 118024 0x1 IND (1)] has the bad pointer (14) to the block (823874804)
```

Then it error out and gave me some info about bad blocks, the -B switch and getting a new drive. Unfortunately this was on the TV downstairs, so hard to read, can I get that text from anywhere to read properly?

Also, now I'm after recommendations on how to preserve as much data as possible whilst waiting for the new drive to come from the suppliers....

(new drive, mmm... to sata and pci controller or not......)

----------

## pteppic

Right, I've 'tar'ed the partition (seeing as kde has updated since the last known good archive) and stored the errors to a log. ATM there are 27 affected files, most in /usr/include (so no updating ATM), a couple in /usr/portage (so killed the --sync cron job), and a few /usr/share/doc files, so nothing too critical. 

While waiting for my new drive, any other suggestions gratefully received.[/i]

----------

## selig

Also please be aware that if you value your data, it is generally a very bad idea to use reiserfs, especially if you do not have a UPS. For more info look at http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc

I had personal experience with the way fsck works on reiserfs after a desktop PC crash. There were a lot of files, all dumped into /lost+found and the contents of several files in the system (which otherwise seemed to be OK) were mixed up. Thankfully, personal data on that PC was stored on an ext3 filesystem, which suffered some problems too, but there were only a few files in /lost+found and with corresponding directories, so the missing files could be put back into places safely and relatively easily. On the other hand, the root partition (reiserfs) was unrecoverable, I had to reinstall it.

So the morals is: do not use reiserfs for data you do not want to lose. If you do not mind reinstalling the system after a crash, you can use it for storing the programs (root filesystem, /usr and things like that), because it is slightly faster than ext3 under some circumstances.

If you want something "cooler" than ext3 for home use, try JFS. I have been using it for more than half a year on a laptop which suffers frequent power loss due to depleted battery and I have never had problems with it.

----------

## pteppic

Interesting to know, ironically enough, one of the reasons I started using reiser was how quickly it recovered after a non clean shutdown, as back in my linux infancy hardlocking the system was a pretty regular occurrence, and the 'ext2 for /boot reiser for /*' is just the way I do things out of habit.

Now the box in question is outside the influence of the UPS and the 'quick, turn off' scripts (wondered for ages why only one shut down on a real power down, of course, you have to put the network switch on the UPS too  :Embarassed:  ) I'll rethink the partitioning scheme for the replacement drive(s).

----------

## selig

Well reiserfs now has a mount option data=journal which makes it somewhat safer. If you want to use it (because of its speed), be sure to put data=journal into your mount command or /etc/fstab. If it is an older computer (pre-amd64 and the like), I would definitely recommend jfs for it. ReiserFS and XFS are quite CPU-intensive, which is good on new hardware but bad on older.

Oh, one more thing - do not use ReiserFS on big partitions. The mount times of big partitions are considerable (means do not use it for partitions larger than 100-150GB). And ReiserFS' performance tends to degrade very quickly over time, it suffers from fragmentation a lot sooner than one would expect. Mr. Reiser provides his customers with a tool that does automatic background defragmentation on the FS, but it costs $$. Manual defragmentation is tedious, but unavoidable, because for a filesystem that has a lot of writes to it, you've got a few months of lifetime at best until it becomes actually slower than ext3.

On the other hand, when you use ext3 with the mount option data=writeback and create (or tune2fs) it with the dir_index option, its performance will improve noticeably. This is about as safe as JFS filesystem.

A quick glance at the choices (at least I would recommend these):

best data safety, slowest: ext3 with data=journal or data=ordered (the latter is faster, but does not journal data, only metadata)

reasonable safety as well as speed: ext3 with data=writeback or JFS

good speed and reasonable safety with the need of extra maintenance: ReiserFS with data=journal

very good speed and horrible safety with the need of extra maintenance: ReiserFS with data=ordered (or no switch, this is the default)

very good speed and horrible safety on PC-class hardware (without a UPS and power-out interrupts): XFS

JFS is the best choice for older hardware (slower CPU). ReiserFS and XFS are unsuitable for older hardware (the CPU cost outweighs FS speed benefits on slower CPUs).

I hope this is at least a bit helpful.

----------

## pteppic

Well, the drive arrived, and stuff got switched around, a lot. The machine was just a desktop when it got promoted to PVR (well promoted in the amount of work it does).

The amount of repetative work done on each partition and how valuable the data is, coupled with the advice given here, aes led to the below layout

/                   ext3

/boot             ext2

/usr              jfs

/usr/portage  reiser (cos this one is the fragmenting directory, and easiest to replace the data)

/var              ext3 

/tmp             reiser

/home           ext3

/var/lib/mysql jfs    (wanted better speed, and nightly backups make recovery fairly painless, plus it's another fragmenting drive)

/mnt/store      jfs    (we all know what this is for, and its the new drive with 5 gig left for holding a stage3 system to save booting from cdrom/usb for maintenance)

/mnt/data       xfs   (existing partition with large video files, used for making dvds etc, plus it held the existing backups, so stayed)

fstab looks like a real mess, but it works, and should continue to do so.

My gentoo bootable usb disk caused grief when I tried to install grub, it put the only IDE drive left on the system as hdg and grub refused to see it, had to take the SATA PCI card out to get it to work, but it's all good now.

Thanks for all the help guys, the machine should prove to need less maintenace (and easier), be more relyable, and more secure (noexec etc on dirs that don't need it) seeing as it runs it's own apache for mythweb now (almost, just need to do the DNAT).

----------

## selig

Actually fstab is now not a mess but exactly how it should look like.   :Wink:   It's good to use each filesystem for what it's best for when we have the choice.

I would say that /tmp is a good candidate for tmpfs, if you do not need to put large files in there (on my desktops I manage with 32-256MB tmpfs mounted in /tmp). That's the fastest option and when you power off it loses all data (since it resides solely in RAM).

I also have /var/tmp mounted as tmpfs (1.5GB) which is good too if you have enough memory, because all compilation in portage then does not have to access the disk for any writes. Well when you want to compile OO.org, you need to unmount it, but for all other software 1.5GB seemed more than enough for me. It does help and since there are no real data which matter, it's a good choice IMHO.

And for /usr/portage I use a plain old ext2 with dir_indexes and block size 1024, FS size around 290MB, number of inodes at 200k or so (I can check this at home for the exact numbers) - this way you lose the least space, because there are just tons of tiny files - and it's reasonably fast as well. I tried all filesystems for miniature files and ext2 with bs 1024 still loses the least capacity when filled up with them. No need to journal anything there, you can have it mounted read-only most of the time, so even on an unclean power-off you do not need to run fsck on the next boot on it. Also if you get a power failure when it is mounter read-write, the fsck is quite fast since it is so small, can run in background (started from local.start) and even if files get lost, all you need to do is resync.

In fact, I am using a filesystem in a file mounted via a loop device for /usr/portage, when I want to transfer it to other computers on the local net, it is moutned read-only and the other computers just download the whole portage.img loop file via ftp. That's a lot faster than rsync, with this many small files. After this transfer clients mount it read-only and do an emerge --metadata .

Although ReiserFS on /usr/portage is a good choice too, because when it gets too fragmented you just need to mkfs it and do a webrsync - and it's back to its full potential.

I hope this filesystem tuning will prove worthwile to you.   :Very Happy:  Glad to share my experience.

----------

