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