From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>
Cc: Phil White <cerise-xfs@l.armory.com>, xfs@oss.sgi.com
Subject: Re: Problem with mkfs.xfs on a regular file
Date: Wed, 27 Nov 2013 23:34:35 -0600 [thread overview]
Message-ID: <5296D5EB.2080008@sandeen.net> (raw)
In-Reply-To: <20131128051626.GM10988@dastard>
On 11/27/13, 11:16 PM, Dave Chinner wrote:
<snip>
> So, it failed to write using direct IO because of IO alignment
> because I didn't tell mkfs that it was running on a file. i.e. I
> forgot the "-d file" option.
>
> $ sudo mkfs.xfs -d size=1g,name=/storage/fubar.img
> meta-data=/storage/fubar.img isize=256 agcount=4, agsize=65536 blks
> = sectsz=512 attr=2, projid32bit=1
> = crc=0
> data = bsize=4096 blocks=262144, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096 ascii-ci=0
> log =internal log bsize=4096 blocks=7344, version=2
> = sectsz=512 sunit=0 blks, lazy-count=1
> realtime =none extsz=4096 blocks=0, rtextents=0
> mkfs.xfs: pwrite64 failed: Invalid argument
> mkfs.xfs: read failed: Invalid argument
>
> Yup, still fails. Let's force it!
>
> $ sudo mkfs.xfs -f -d size=1g,name=/storage/fubar.img
> meta-data=/storage/fubar.img isize=256 agcount=4, agsize=65536 blks
> = sectsz=512 attr=2, projid32bit=1
> = crc=0
> data = bsize=4096 blocks=262144, imaxpct=25
> = sunit=0 swidth=0 blks
> naming =version 2 bsize=4096 ascii-ci=0
> log =internal log bsize=4096 blocks=7344, 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
> mkfs.xfs: read failed: Invalid argument
>
> And there's the identical failure to what was reported.
>
> So, user error - the user is telling mkfs.xfs that it is making a
> filesystem on a block device named "/storage/fubar.img". The same
> thing happens with the normal method of specifying the block device:
If only we had some way to tell, programatically, whether the mkfs target
was a regular file or a block device, eh? ;)
Seriously, I always thought the requirment to specify "-d file" was silly.
And now I think it's even more silly, if it actually is required for
proper behavior...
> What mkfs needs to do is reject devices that are files when "-d
> file", "-l file" and "-r file" is not specified, and the problem
> will go away because it will catch users who forget to tell mkfs
> that it is supposed to be operating on an image file...
Or maybe just stat() it, and DTRT?
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-11-28 5:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-27 2:31 Problem with mkfs.xfs on a regular file Phil White
2013-11-27 2:36 ` Phil White
2013-11-27 2:38 ` Nathan Scott
2013-11-27 2:41 ` Phil White
2013-11-27 2:47 ` Dave Chinner
2013-11-27 2:47 ` Dave Chinner
2013-11-28 2:39 ` Eric Sandeen
2013-11-28 5:16 ` Dave Chinner
2013-11-28 5:34 ` Eric Sandeen [this message]
2013-11-28 10:01 ` Dave Chinner
2013-11-28 11:47 ` Phil White
2013-11-28 15:38 ` Eric Sandeen
2013-11-28 15:32 ` Eric Sandeen
2013-11-28 21:12 ` Dave Chinner
2013-11-29 1:28 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5296D5EB.2080008@sandeen.net \
--to=sandeen@sandeen.net \
--cc=cerise-xfs@l.armory.com \
--cc=david@fromorbit.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.