All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.