Bug 1101228 - mkfs.xfs fails on sparse files
mkfs.xfs fails on sparse files
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: xfsprogs (Show other bugs)
rawhide
s390x Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
Depends On:
Blocks: ZedoraTracker 1101112 1101236
  Show dependency treegraph
 
Reported: 2014-05-26 08:25 EDT by Dan Horák
Modified: 2014-06-17 02:14 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1101236 (view as bug list)
Environment:
Last Closed: 2014-06-16 22:23:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace log of the mkfs.xfs run (8.64 KB, text/plain)
2014-05-26 08:28 EDT, Dan Horák
no flags Details

  None (edit)
Description Dan Horák 2014-05-26 08:25:22 EDT
[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.
Comment 1 Dan Horák 2014-05-26 08:28:45 EDT
Created attachment 899303 [details]
strace log of the mkfs.xfs run
Comment 2 Eric Sandeen 2014-05-26 21:30:10 EDT
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?
Comment 3 Eric Sandeen 2014-05-26 21:35:50 EDT
Also, what if you don't use "-f" ?
Comment 4 Dan Horák 2014-05-27 02:29:18 EDT
(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)
Comment 5 Dan Horák 2014-05-27 02:30:26 EDT
(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
Comment 6 Eric Sandeen 2014-05-27 14:18:09 EDT
Heh, ok, thanks for testing.
Comment 7 Eric Sandeen 2014-05-27 15:24:32 EDT
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.
Comment 8 Eric Sandeen 2014-05-27 15:25:41 EDT
                   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.
Comment 9 Eric Sandeen 2014-05-27 15:36:04 EDT
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.
Comment 10 Dan Horák 2014-05-27 15:47:36 EDT
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.
Comment 11 Eric Sandeen 2014-05-27 17:31:59 EDT
Ok, thanks - I'll still try to make it more graceful, automatic, or obvious.

-Eric
Comment 12 Eric Sandeen 2014-06-16 22:23:57 EDT
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
Comment 13 Dan Horák 2014-06-17 02:14:23 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.