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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
