CF card failing, what to do?

O

overmind

I have a Samba Server that uses FreeBSD 7.2 installed on a Compact Flash (with IDE adapter), booting from IDE, using SATA drives only for storage.

Few days ago crashed, and now it will not boot. Doing a fsck on that CF card I get:

Code: 
# fsck -t ufs -y /dev/da2s1a
** /dev/da2s1a
BAD SUPER BLOCK: VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE
ioctl (GCINFO): Inappropriate ioctl for device
fsck_ufs: /dev/da2s1a: can't read disk label

So I think either:
- my CF is failing (I probably could try to fdisk/disklabel/newfs-it).
- CF is ok but file sistem is messed up because of a system crash? (I only have few crashes last 4-5 months)

I've run FreeBSD for like an year or so (7.0 first) with no problems until now, I also had mounted CF in fstab with "noatime" to protect compact flash card.

So my questions are:
1. in my current setup with few logs written to CF, with no atime how much time will work my server until CF fails? (assuming that I have a good - brandname CF)

2. what should I do to protect this from happening? (should I use ZFS or gjournal? or what other choices are and which is best, considering it is about a CF with limited writes, and not a hard drive)

thank you and best regards
 
This is a corrupted filesystem, most likely due to the power fail. The superblock is the core of the UFS filesystem. This block tells it where everything begins. If you can't access the superblock, you can't access the filesystem. Which is why UFS keeps a bunch of backups of the superblock (you see this in the output of the newfs command when you format a UFS filesystem).

The error is saying that the main UFS superblock does not match the first backup of the superblock, and it doesn't know which one to use.

You have to tell the filesystem to use an alternate superblock. Unfortunately, I don't know how to find out where the others are stored, or how to tell fsck to use an alternate. I do recall a few threads on the mailing lists over the years with solutions to this issue, though, so you should be able to find the info via a web and/or mailing list archive search.
 
160 is pretty common for the first backup superblock, so try # fsck_ffs -b 160 /dev/da2s1a. You can (I believe) fake a newfs with -N and see what it would have done for backup superblocks as well (assuming you use the same -b that you originally used (I don't think that -f or -i has any effect, but i could most certainly be very wrong (edit: I am very wrong about this, -f really changes stuff)))

(also looks like [cmd=*]tunefs -p /dev/da2s1a[/cmd] gives some values.

NB:
Code: 
[red]> newfs -N ad4s1a[/red]
/dev/ad4s1a: 384.0MB (786432 sectors) block size 16384, fragment size 2048
        using 4 cylinder groups of 96.02MB, 6145 blks, 12352 inodes.
super-block backups (for fsck -b #) at:
 160, 196800, 393440, 590080
[red]> newfs -N -b 8192 ad4s1a[/red]
/dev/ad4s1a: 384.0MB (786432 sectors) block size 8192, fragment size 2048
        using 5 cylinder groups of 82.75MB, 10592 blks, 10592 inodes.
super-block backups (for fsck -b #) at:
 144, 169616, 339088, 508560, 678032
[red]> newfs -N -b 8192 -f 1024 ad4s1a[/red]
/dev/ad4s1a: 384.0MB (786432 sectors) block size 8192, fragment size 1024
        using 9 cylinder groups of 45.13MB, 5777 blks, 11584 inodes.
super-block backups (for fsck -b #) at:
 144, 92576, 185008, 277440, 369872, 462304, 554736, 647168, 739600
 
Hello

I did that and at least I could be able to fsck it. It was messed up, a lot of files were corrupted.
Also trying to reinstall FreeBSD on that card failed. I think some parts of the CF are broken, my system freezes at installation.

Is possible to use gjournal to prevend this kind of things from happening?
If I do that, I will have more writes to the CF card? (it will shorten it's life?)

Thank you
 
overmind said:
Hello

I did that and at least I could be able to fsck it. It was messed up, a lot of files were corrupted.
Also trying to reinstall FreeBSD on that card failed. I think some parts of the CF are broken, my system freezes at installation.

Is possible to use gjournal to prevend this kind of things from happening?
If I do that, I will have more writes to the CF card? (it will shorten it's life?)

Thank you
Click to expand...

From what I know of journaling you'll probably get more writes, yes. & gjournal won't protect you from massive disk corruption much better. I'd suggest using the CF to load an MFS root, though I don't know where you should swap. A file in your samba share, maybe?

Better quality solid state drives have a mean time between failures as good as or better than regular HDDs, so you might look into that.
 
You must log in or register to reply here.
Back
Top