On 12/15/16 6:53 PM, Dave Chinner wrote: > On Thu, Dec 15, 2016 at 12:21:43PM -0600, Eric Sandeen wrote: >> On 12/6/16 9:47 PM, Dave Chinner wrote: >>> From: Dave Chinner <dchinner@xxxxxxxxxx> >>> >>> It makes no sense to iterate the file table for some xfs_io >>> commands. Some commands are already marked in this way, but lots of >>> them are not and this leads to bad behaviour. For example, the open >>> command will run until the process fd table is full and EMFILE is >>> returned rather than just opening the specified file once. >> >> Ok, I'm not quite clear on when we should expect commands to be >> "oneshot" >> >> With freeze, for example, this: >> >> xfs_io -x -c freeze mnt/file mnt2/file >> >> will freeze both filesystems today. With this change, > > xfs_freeze will ignore multiple filesystem options, so it only ever > passes a single file to xfs_io. IOWs, it's behaviour will be > completely unchanged by making the xfs_io freeze command a one-shot > command. Sure, but xfs_freeze is not xfs_io, it's a wrapper which by design presents /simple/ single-fs arguments to xfs_io. > And right now, I think that's the only case we have to care about. > unless someone is actually using xfs_io directly to freeze multiple > filesystems like this, then I think it's better to make it a > one-shot command. > >> xfs_io -x -c freeze mnt/file mnt2/file >> >> freezes the mnt2 filesystem but not mnt. Is that desired? > > It's exactly what the man page says the freeze command does. > >> I guess the command /is/ documented as "freeze fs of /current/ file" >> but i wonder if that's just an accident of documentation. > > If the man page documents it as operating on the current file, > but instead it freezes all the open files, then that's a bug that > needs fixing. yes, in either the man page /or/ the code... >> ditto for i.e. the inode command, or resblks - why not >> iterate those? > > Because they are aimed at single, specific filesystem operations > only. It just doesn't make sense to iterate them across all open > files inside xfs_io. If you have multiple filesystems youneed to > query/modify, then do an xfs_io call for each. Ok, I guess this finally clicked for me; a very easily described test for whether the flag gets set: Only operations which specifically operate on /files/ will iterate*. System-wide and fs-wide operations (even if they happen to take a file as an argument, as i.e. freeze can) do /not/ iterate. *and open doesn't iterate because recursion :) I'm happy with that, though I think it should be documented clearly. Sorry if I was slow getting to your point. -Eric > Cheers, > > Dave. > -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html