| 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@xxxxxxxxxxxxxx> |
| References: | <20050926071451.GA3751@xxxxxxxxxxxxxxxxx> <4338128F.8000707@xxxxxxx> <20050927163531.GA19652@xxxxxxxxxxxxxxxxx> <433976C5.1000104@xxxxxxx> <20050929054410.GA30789@xxxxxxxxxxxxxxxxx> <20051001091130.GA15808@xxxxxxxxxxxxxxxxx> <434174A7.6010904@xxxxxxx> <26743c10510031244x726ff508m89ecd0398417e521@xxxxxxxxxxxxxx> |
| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: Contribution to XFS on Linux <Support block sizes larger than the page size>, David Chinner |
|---|---|
| Next by Date: | The XFS real-time subvolume in Linux, Dubravko Markic |
| Previous by Thread: | Re: ls -l versus du -sk after xfs_fsr, Mathieu Betrancourt |
| Next by Thread: | Re: ls -l versus du -sk after xfs_fsr, Ludek Finstrle |
| Indexes: | [Date] [Thread] [Top] [All Lists] |