Messages in this thread | | | Date | Thu, 12 Mar 2009 00:11:56 +0100 | From | François Cami <> | Subject | Re: 2.6.28.7/ext2/e2fsprogs-1.41.3: apparently irreparable filesystem damage, filesystem not imageable |
| |
On Wed, 11 Mar 2009 21:52:15 +0000 Nix <nix@esperi.org.uk> wrote:
(...)
> OK, time to image it to another ext2 filesystem with enough space (there > isn't enough unpartitioned space, we have to put it in a file). We imaged > from an LVM snapshot to ensure that nothing could possibly futz with the fs > while we imaged it: > > ,---- > | root@beast:/var/log/fsck# dd if=/dev/disks/home-snap of=/mnt/horizon/home.img bs=10240000 & DDPID=$! > | [1] 2821 > | [...] > | root@beast:/var/log/fsck# while sleep 30; do kill -USR1 $DDPID; done > | 1665+0 records in > | 1664+0 records out > | 17039360000 bytes (17 GB) copied, 1611.98 s, 10.6 MB/s > | dd: writing `/mnt/horizon/home.img': File too large > | 1685+0 records in > | 1684+0 records out > | 17247252480 bytes (17 GB) copied, 1630.96 s, 10.6 MB/s > | [1]+ Exit 1 dd if=/dev/disks/home-snap of=/mnt/horizon/home.img bs=10240000 > `---- > > The only phrase that springs to mind now is 'WTF'? I've never heard of a > 17Gb -EFBIG limit before. Certainly it's not O_LARGEFILE-related: a > quick strace shows dd(1) opening both inputs and outputs with > O_LARGEFILE, as everyone has since the year dot. Some completely weird > kernel bug? > > What on earth is going on?
AFAIK you are hitting the 16GB file size limit of a 1KB-block formatted ext{2,3} filesystem on /mnt/horizon/ .
François -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |