On 7/28/15 8:13 AM, Leslie Rhorer wrote: > On 7/28/2015 7:33 AM, Brian Foster wrote: >> On Tue, Jul 28, 2015 at 02:46:45AM -0500, Leslie Rhorer wrote: >>> On 7/20/2015 6:17 AM, Brian Foster wrote: >>>> On Sat, Jul 18, 2015 at 08:02:50PM -0500, Leslie Rhorer wrote: ... >>>> would try to hopefully isolate a filesystem problem from something >>>> underneath: >>>> >>>> xfs_metadump -go /dev/md0 /somewhere/on/rootfs/md0.metadump >>>> xfs_mdrestore -g /somewhere/on/rootfs/md0.metadump /.../fileonrootfs.img >>>> mount /.../fileonrootfs.img /mnt/ >>> >>> I tried to do the xfs_mdrestore to the root file system, but it fails: >>> >>> RAID-Server:/TEST# xfs_mdrestore -g md0.metadump RAIDfile.img >>> xfs_mdrestore: cannot set filesystem image size: File too large >>> >> >> 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. -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs