| To: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: xfs_check does not recognize fs truncation |
| From: | Jan Engelhardt <jengelh@xxxxxxxxxx> |
| Date: | Fri, 28 Aug 2009 12:14:04 +0200 (CEST) |
| Cc: | xfs@xxxxxxxxxxx |
| In-reply-to: | <alpine.LSU.2.00.0908241714410.17924@xxxxxxxxxxxxxxxxxxxxxxxxx> |
| References: | <alpine.LSU.2.00.0908241208520.1028@xxxxxxxxxxxxxxxxxxxxxxxxx> <20090824144752.GA20898@xxxxxxxxxxxxx> <alpine.LSU.2.00.0908241714410.17924@xxxxxxxxxxxxxxxxxxxxxxxxx> |
| Sender: | jengelh@xxxxxxxxxxxxxxxxxxxxxxxxx |
| User-agent: | Alpine 2.00 (LSU 1167 2008-08-23) |
On Monday 2009-08-24 18:04, Jan Engelhardt wrote: >On Monday 2009-08-24 16:47, Christoph Hellwig wrote: >>On Mon, Aug 24, 2009 at 12:12:59PM +0200, Jan Engelhardt wrote: >>> >>> This I see on xfsprogs-2.10.1 with kernel 2.6.29.6: >> >>What does xfs_repair -n say? > >[success] > >You can get the image at >http://dev.medozas.de/files/linux-hist.img.lzma [179MB->1782MB] > If I pad the image with at least 20480*512 NUL bytes to a total of 1879048192 bytes, xfs (kernel side) starts to accept the image and will mount it. The steps to return to the previous problematic size is as follows: # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/loop0 1824768 1274824 549944 70% /mnt/linux-hist # truncate --size=$((1824768*1024)) linux-hist.img |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: xfs data loss, Passerone, Daniele |
|---|---|
| Next by Date: | Re: Kernel 2.6.30.4 loop(..?) regression (& with/2.6.31-rc6), Justin Piszcz |
| Previous by Thread: | Re: xfs_check does not recognize fs truncation, Jan Engelhardt |
| Next by Thread: | Changing a file system from case sensitive to case insensitive..., Linda A. Walsh |
| Indexes: | [Date] [Thread] [Top] [All Lists] |