|To:||Leslie Rhorer <lrhorer@xxxxxxxxxxxx>, Sean Caron <scaron@xxxxxxxxx>|
|Subject:||Re: Corrupted files|
|From:||Sean Caron <scaron@xxxxxxxxx>|
|Date:||Tue, 9 Sep 2014 11:50:28 -0400|
If you have a full backup, I would STRONGLY recommend just wiping your old filesystem and restoring your backups on top of a totally fresh XFS, rather than repairing the original filesystem and then filling in the blanks with backups using a file-diff tool like rsync.
You will probably hear various opinions here about xfs_repair; my personal opinion is that xfs_repair is a program made available for the unwary to further scramble their data and make a hash of the filesystem... In my first-hand experience managing ~7 PB of XFS storage and growing, I have NEVER found xfs_repair (yes, even the "newest version") to ever do anything positive. It's basically a data scrambler.
At this point, you will never achieve anything near what I'd consider a production-grade, trustworthy data repository. Any further runs of xfs_repair will either do nothing, or make the situation worse. Fortunately you followed best practice and kept backups so you don't really need xfs_repair anyway, right?
P.S. No backups? Still don't even think about running xfs_repair. ESPECIALLY don't think about running xfs_repair. Try mounting ro; if that doesn't work, mount ro with noreplaylog and scavenge what you can. Write off the rest. That's the cost of doing business without backups. Running xfs_repair (especially as a first-line step) will only make it worse, and especially on big filesystems, the run time can extend to weeks... Don't keep your users down any longer than you need to, running a program that won't really help you. Just scavenge it, reformat and turn it back around.
On Tue, Sep 9, 2014 at 11:21 AM, Leslie Rhorer <lrhorer@xxxxxxxxxxxx> wrote:
|<Prev in Thread]||Current Thread||[Next in Thread>|