Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1101228 - mkfs.xfs fails on sparse files
Summary: mkfs.xfs fails on sparse files
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: xfsprogs
Version: rawhide
Hardware: s390x
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ZedoraTracker 1101112 1101236
TreeView+ depends on / blocked
 
Reported: 2014-05-26 12:25 UTC by Dan Horák
Modified: 2018-01-31 13:01 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1101236 (view as bug list)
Environment:
Last Closed: 2014-06-17 02:23:57 UTC
Type: Bug
Embargoed:


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

Description Dan Horák 2014-05-26 12:25:22 UTC
[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 12:28:45 UTC
Created attachment 899303 [details]
strace log of the mkfs.xfs run

Comment 2 Eric Sandeen 2014-05-27 01:30:10 UTC
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-27 01:35:50 UTC
Also, what if you don't use "-f" ?

Comment 4 Dan Horák 2014-05-27 06:29:18 UTC
(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 06:30:26 UTC
(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 18:18:09 UTC
Heh, ok, thanks for testing.

Comment 7 Eric Sandeen 2014-05-27 19:24:32 UTC
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 19:25:41 UTC
                   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 19:36:04 UTC
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 19:47:36 UTC
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 21:31:59 UTC
Ok, thanks - I'll still try to make it more graceful, automatic, or obvious.

-Eric

Comment 12 Eric Sandeen 2014-06-17 02:23:57 UTC
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 06:14:23 UTC
(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.