xfs
[Top] [All Lists]

Re: ls -l versus du -sk after xfs_fsr

To: Mathieu Betrancourt <mbetrancourt@xxxxxxxxx>
Subject: Re: ls -l versus du -sk after xfs_fsr
From: Eric Sandeen <sandeen@xxxxxxx>
Date: Mon, 03 Oct 2005 21:22:56 -0500
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <26743c10510031244x726ff508m89ecd0398417e521@mail.gmail.com>
References: <20050926071451.GA3751@soptik.pzkagis.cz> <4338128F.8000707@sgi.com> <20050927163531.GA19652@soptik.pzkagis.cz> <433976C5.1000104@sgi.com> <20050929054410.GA30789@soptik.pzkagis.cz> <20051001091130.GA15808@soptik.pzkagis.cz> <434174A7.6010904@sgi.com> <26743c10510031244x726ff508m89ecd0398417e521@mail.gmail.com>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
Mathieu Betrancourt wrote:
hi,

I have the same problem on a xfs on a raid 1 device (mdraid), wich is almost
full (97%)
and not on other non raid devices (and unfortunately not almost full).

This problem appeared under Fedora3 and Suse9.3

Here's the output of xfs_info for the problematic one :

Thanks, good (I guess!) to know that it's reproducible... so far we have not been able to reproduce it in-house.


Mathieu, are you also using acls and/or extended attributes?

It would also be interesting to see the xfs_repair output, and xfs_bmap (-v and -a) output of the problematic files prior to running xfs_fsr, if possible.

Thanks,

-Eric


<Prev in Thread] Current Thread [Next in Thread>