And in fact, after 32 years adminning *nix boxes for a living, yes, I do expect that if any userland program can /corrupt/ FS internals without twiddling with /dev/sdX, either the FS is broken or the hardware is.
In this case I'm quite certain it /was/ the hardware, and 85-90% confident it's fixed now.
Cheers,
-jra
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> wrote:
On 8/18/2013 4:38 PM, Jay Ashworth wrote:
> I'm trying to dedupe the two large XFS filesystems on which I have DVR
> recordings, so that I can walk around amongst the available HDDs and create
> new filesystems under everything.
>
> Every time I rm a file, the filesystem blows up, and the driver shuts it
> down.
>
> Some background:
>
> At the moment, I have 2 devices, /dev/sdd1 mounted on /appl/media4, and
> /dev/sda1 mounted on /appl/media5, and a large script, created by hand-
> hacking the output of a perl dupe finder script.
>
> The large script was mangled so that it would remove anything that was a
> dupe from media4, unless the file was an unlabeled lost+found on media5,
> and had a name on media4. In that case, I removed the file on media5, and
> ; then moved it from media4 to media5.
>
> After the hand-hacking on the script, I sorted it to do all the rm's first,
> and then all the mv's, to make sure free space when up before it went down.
>
> And, of course, when I ran the script, it caused the XFS driver to cough and
> die, leading to error 5s and gnashing of teeth.
If this script is the catalyst of your XFS problems, it seems logical
that you would include said script in your trouble report, yet you did
not. It's a bit foolish to assume you can't break a Linux subsystem
with a poorly written program and/or in combination with a platform that
isn't up to the task being asked of it. As Joe mentioned having too
little RAM could be part of this problem.
--
Stan
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs