With dev/backup I mean if the Linux machine you're running is a a
backup system or a development machine that you can at least test this
on, it'd be convenient.
The reason why you can't mount even though repair suggests you do
might be because of a bug in xfsprogs/libs not a complete corruption
in the filesystem itself.
Perhaps even the newer version of the progs & libs might be able to
handle the kind of corruption in the filesystem you're having now,
without the need to clear the log.
In case you resort to clearing the log, wouldn't running xfs_repair
result in eventually finding the lost inodes and putting them in
lost+found?
On Sat, Dec 19, 2009 at 10:02 PM, Leslie Rhorer <lrhorer@xxxxxxxxxxx> wrote:
>> Do any of the disks report sector errors or ATA or read errors?
>> smartctl -a /dev/sdx should give the report, assuming you run smartd
>> and have it probe disks periodically.
>
> No, they are clean.
>
>> I've seen newer versions of the xfsprogs and libs packages. Try using
>> those. I know you're against new packages that haven't been included
>> in "stable" -- but if this is a dev/backup system, it's worth the shot
>> in my opinion.
>
> Well, either way, that's not going to help in this situation.
> Either there is something I can attempt to fix in the underlying array
> structure, or else I am going to have to erase the log and continue.
>
> I'm not sure what you mean by dev/backup. The file system is not
> created as a device on any other system by udev, if that's what you mean.
> It's just a Linux system dedicated solely to running rscync backups every
> morning at 04:00. The array does get mounted on other systems using SAMBA
> or NFS, as the case may be, so I can easily copy over files to the main
> systems lost or corrupted through whatever means.
>
>
--
Majed B.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
