Re: Problem with mkfs.xfs on a regular file

[Eric Sandeen <sandeen@sandeen.net>]

On 11/28/13, 5:47 AM, Phil White wrote:
> On Thu, Nov 28, 2013 at 09:01:07PM +1100, Dave Chinner wrote:
>> On Wed, Nov 27, 2013 at 11:34:35PM -0600, Eric Sandeen wrote:
>>> 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...
>>
>> It has always been required if you want mkfs to create the file for
>> you. And given that doing stuff like ioctl(BLKDISCARD) on files is
>> completely wrong, so I think it really is needed...
>>
>>>> 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?
>>
>> 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?
> 
> FWIW, I have a patch to just stat() and discard LIBXFS_DIRECT if the
> target is not a block device.  It worked for what I was doing and I
> wouldn't mind cleaning it up if need be.

I wonder if that's a little too surgical; today if we specify -d file,
we get xi.disfile=1, and set xi.dcreat=1 as well as long as -N wasn't specified.

Having xi.disfile set affects a few other behaviors after all, so
I just wonder if we should stat it early, set xi.disfile, and let all the
normal paths take it from there.  I'm not quite sure.

> The main thing is that it seems to me that mkfs mandates that the situation
> I outlined shouldn't ever fail.  That's probably something worth adding to
> xfstests as well.
> 
> And writing that test, I suppose, is something I don't mind doing either.

Tests are always welcome, that'd be great!

Thanks,
-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs