xfs
[Top] [All Lists]

Re: XFS File system in trouble

To: xfs@xxxxxxxxxxx
Subject: Re: XFS File system in trouble
From: Martin Steigerwald <martin@xxxxxxxxxxxx>
Date: Tue, 28 Jul 2015 21:52:45 +0200
Cc: Martin Papik <mp6058@xxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <55B7D400.50202@xxxxxxxxx>
References: <03864DDC681E664EBF5D47682BE7D7CF0D3574DF@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <55B7B390.1050206@xxxxxxxxxxx> <55B7D400.50202@xxxxxxxxx>
User-agent: KMail/4.14.5 (Linux/4.2.0-rc3-tp520-btrfstrim+; KDE/4.14.2; x86_64; ; )
Am Dienstag, 28. Juli 2015, 22:12:00 schrieb Martin Papik:
> >>> Hmm, I guess the file size exceeds the capabilities of the root
> >>> fs, even if there might ultimately be enough space to restore
> >>> the metadump.
> >> 
> >> I wouldn't think so, at least not fundamentally. It's ext4. It's
> >> certainly not big enough to hold an 18T file system, though, and
> >> perhaps that is what xfs_restore is checking.
> > 
> > No, it's just failing to write any data at an 18T offset.
> > 
> > The ext4 filesystem (with 4k blocks) is limited to a 16T maximum
> > file offset; you won't be able to restore a (sparse) 18T
> > filesystem image onto an ext4 filesystem.

> How about this?
> 
> qemu-img create -f qcow2 test 32T
> qemu-nbd -c /dev/nbd0 test
> xfs_mdrestore -g md0.metadump /dev/nbd0

I used an XFS filesystem with truncate command to create an 1 EiB XFS 
filesystem in a sparse file for testing a year or two ago. It took about 18 
GiB for writing metadata and journal at mkfs.xfs time.

With df -h you get "1E" and with df without option you get an really large 
number :)

Thanks,
-- 
Martin

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