Bug 1101228
| Summary: | mkfs.xfs fails on sparse files | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dan Horák <dan> | ||||
| Component: | xfsprogs | Assignee: | Eric Sandeen <esandeen> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | esandeen, hannsj_uhl | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | s390x | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 1101236 (view as bug list) | Environment: | |||||
| Last Closed: | 2014-06-17 02:23:57 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 467765, 1101112, 1101236 | ||||||
| Attachments: |
|
||||||
Created attachment 899303 [details]
strace log of the mkfs.xfs run
Ugh. Trying to do a 512 byte direct IO on a fileystem presumably living on a hard-4k block device. What kernel did you test this on, and what filesystem hosted the sparse file? Also, what if you don't use "-f" ? (In reply to Eric Sandeen from comment #2) > Ugh. > > Trying to do a 512 byte direct IO on a fileystem presumably living on a > hard-4k block device. correct, it's on a dasd > What kernel did you test this on, and what filesystem hosted the sparse file? kernel-3.14.3-200.fc20.s390x and ext4 kernel-3.10.0-123.el7.s390x and xfs (the rhel7 cloned bug #1101236) FWIW those 2 commands are from parted test case (bug #1101112) (In reply to Eric Sandeen from comment #3) > Also, what if you don't use "-f" ? [sharkcz@devel6 tmp]$ strace -ff -o mkfs.log mkfs.xfs loop-file meta-data=loop-file isize=256 agcount=4, agsize=8224 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 data = bsize=4096 blocks=32896, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=853, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 mkfs.xfs: pwrite64 failed: Invalid argument Heh, ok, thanks for testing. Oh, I remember now. This will work: # mkfs.xfs -dfile,name=mnt/fsfile,size=128m in which you explicitly tell it that you are creating a file. This will also work: # losetup /dev/loop0 mnt/fsfile # mkfs.xfs /dev/loop0 Granted, we should probably just recognize that it's a file, but for now, those 2 options might be decent workarounds.
file[=value]
This is used to specify that the file given by the
name suboption is a regular file. The value is either
0 or 1, with 1 signifying that the file is regular.
This suboption is used only to make a filesystem
image. If the value is omitted then 1 is assumed.
Actually I'm leaning towards NOTABUG on this one. The utilities all have switches to explicitly say whether or not we're working on a file. Things might work without it, but it's not documented to do so. The problematic parted test has been migrated to the -dfile,name=mnt/fsfile,size=128m form a moment ago, so my only objection for not closing it now, is to make mkfs.xfs fail more gracefully, eg. with some error message about different sector sizes or something like that. Ok, thanks - I'll still try to make it more graceful, automatic, or obvious. -Eric Upstream, I sent: [PATCH 1/2 V2] xfsprogs: try to handle mkfs of a file on 4k sector device [PATCH 2/2 V3] mkfs.xfs: don't call blkid_get_topology on existing regular files which should make this work better, but for now I think I'll close this UPSTREAM; there is a workaround & you've already implemented it, and I've made things a bit simpler/better upstream. If you need this in Fedora before the next xfsprogs rebase for some reason just let me know. Thanks for the report, -Eric (In reply to Eric Sandeen from comment #12) > Upstream, I sent: > > [PATCH 1/2 V2] xfsprogs: try to handle mkfs of a file on 4k sector device > [PATCH 2/2 V3] mkfs.xfs: don't call blkid_get_topology on existing regular > files > > which should make this work better, but for now I think I'll close this > UPSTREAM; there is a workaround & you've already implemented it, and I've > made things a bit simpler/better upstream. > > If you need this in Fedora before the next xfsprogs rebase for some reason > just let me know. > > Thanks for the report, > -Eric Thanks for the fix, the parted test case uses now a different way when calling mkfs.xfs, so there is no need to backport the changes to Fedora xfsprogs. |
[sharkcz@devel6 tmp]$ dd if=/dev/null of=loop-file bs=512 seek=263168 0+0 records in 0+0 records out 0 bytes (0 B) copied, 0.000263063 s, 0.0 kB/s [sharkcz@devel6 tmp]$ mkfs.xfs -f loop-file meta-data=loop-file isize=256 agcount=4, agsize=8224 blks = sectsz=512 attr=2, projid32bit=1 = crc=0 data = bsize=4096 blocks=32896, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 log =internal log bsize=4096 blocks=853, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 existing superblock read failed: Invalid argument mkfs.xfs: pwrite64 failed: Invalid argument Version-Release number of selected component (if applicable): xfsprogs-3.2.0-1.fc20.s390x Additional information: This problem doesn't occur on x86_64 and ppc64.