xfs
[Top] [All Lists]

Re: Problem with mkfs.xfs on a regular file

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: Problem with mkfs.xfs on a regular file
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 28 Nov 2013 09:32:32 -0600
Cc: Phil White <cerise-xfs@xxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20131128100107.GN10988@dastard>
References: <20131127023119.GB13101@boogeyman> <20131127024713.GE10988@dastard> <5296ACFB.4030901@xxxxxxxxxxx> <20131128051626.GM10988@dastard> <5296D5EB.2080008@xxxxxxxxxxx> <20131128100107.GN10988@dastard>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
On 11/28/13, 4:01 AM, Dave Chinner wrote:
> On Wed, Nov 27, 2013 at 11:34:35PM -0600, Eric Sandeen wrote:

<snip>

>> Or maybe just stat() it, and DTRT?
> 
> Well, we need to stat it to make sure that it's a file if "-d file"
> is specified, and a block device if it's not. That will prevent this
> problem.  Every other xfsprogs utility has to be told that it is
> being pointed at an image file rather than a block device, so why
> should mkfs be any different?

The option is there but again I never really knew why.  They work
fine without -f, at least in general:

$ xfs_db fsfile
xfs_db> 

$ xfs_repair fsfile
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
...

$ xfs_metadump fsfile fsfile.meta

$ file fsfile.meta
fsfile.meta: XFS filesystem metadump image

etc

> Indeed, if we don't require users to tell mkfs that it's a file,
> what do we do with non-existent  device names when they are provided
> by the user? Just create the file rather than returning ENOENT? So
> suddenly /dev/ fills up with fileystem images because of typos?

That won't happen because it doesn't create a new file unless -d file
is specified, so I guess that's one difference.  i.e. with -d file
it'll create a file of the requested size; without it, it will mkfs
it to whatever size the file already is, or if it doesn't exist,
return -ENOENT.

> Principle of Least Surprise says that ENOENT is the correct
> behaviour, hence it follows that "-d file" is needed and should be
> properly checked and enforced. I'll add this to the start of the
> patch set I'm currently working on that fixes all of the mkfs input
> parameter validation problems I've found over the past couple of
> weeks...

Well, I hope it doesn't stop mkfs.xfs from mkfs'ing an existing
file image, which has always worked before...

Thanks,
-Eric

> Cheers,
> 
> Dave.
> 

<Prev in Thread] Current Thread [Next in Thread>