Dear Maintainer,
When xfs_freeze -f /some/path is executed and /some/path does not contain a
mounted file system the under lying (in my case root) file system was frozen,
this then required travelling to the site to power cycle the machine. The
mount point normally hosted a removable drive, but it had been ejected.

Please have xfs_freeze return an error if the mountpoint argument does not
contain a mounted file system.
The documentation implies that the argument must be a mount point, but _any_
path provided as an argument will freeze the parent file system.

It probably makes sense to only allow it for mountpoints, then again
I fear people might already be using it differently in existing scripts.

Maybe be should add an -s / --strict option that forces it to only work
on mountpoints?

It probably makes sense to only allow it for mountpoints, then again
I fear people might already be using it differently in existing scripts.

Maybe be should add an -s / --strict option that forces it to only work
on mountpoints?

Well it's your call, but I'll make my case for changing it.
- I think it is very dangerous default behaviour, particularly in
scripts as it can prevent
the possibility of logging in to unfreeze a frozen root.
- The docs all strongly imply that it operates on mountpoints, so surely
not many people
would have diliberately used it on general paths?"
         xfs_freeze -f | -u mount-point"
"The mount-point argument is the pathname of  the  directory  where  the
        file system  is  mounted."
- Because of the name and the wording of the man page, you don't expect
xfs_freeze to
freeze an ext4 file system that isn't even mounted on the path you pass
to it?!
- It's logical to have it work on mountpoints only. You wouldn't expect
umount or fdisk to
work the same way? Do any other partition level tools work this way?
- At the very least I would expect it to require a 'force' option if it
was going to freeze
the root system.

Thanks.

If you are running scripts remotely and they don't handle errors
properly, then that's your problem....

I use it that way all the time. I didn't even realise the man page
says "mount points only".....

Yes, I do expect it to freeze the filesystem under the directory
that is passed, regardless of whether it is a mount point or not.
The man page is wrong.

For example, when you have a directory tree quota set up and
exported by NFS, the users will only know the export path of the
root of the directory tree, and they expect that to behave as if
that is a filesystem mounted at that point. Hence we have to be able
to support freeze being issued at such locations, not just the root
of the filesystem.

FWIW, fsfreeze says exactly the same thing in the man page, but
behaves identically to xfs_freeze...

No, but filesystem utilities are not partition level tools and
expecting them to work the same way is incorrect.

If you can't unfreeze the root filesystem by running xfs-freeze -u
immediately afterwards then that's a filesystem bug, not a problem
with the userspace command.

Cheers,

Dave.

 > If you are running scripts remotely and they don't handle errors
 > properly, then that's your problem....

OK, can you then fix the man page to describe the real behaviour of the
program so that users have a chance to intelligently decide what error
checking to do in their scripts.
I.E the argument isn't a mount point, it's a path, and perhaps use
'filesystem' rather than 'xfs' consistently.

 > If you can't unfreeze the root filesystem by running xfs-freeze -u
 > immediately afterwards then that's a filesystem bug, not a problem
 > with the userspace command.

It may also be a good idea to point out in the man page that you should be
extremely careful running this if you are not logged in interactively,
even a
disconnected ssh session will prevent you running xfs_freeze -u to manually
unfreeze the root filesystem.
Thanks
Pat Emblen

Patches to fix the documentation are welcome...

From the man page:

    In  Linux  kernel  version  2.6.29,  the interface which XFS
    uses to freeze and unfreeze was elevated to the VFS, so that
    this tool can now be used on many other Linux filesystems.

Sure. Patches are welcome. ;)

Cheers,

Dave.

A patch for the man page is (hopefully) attached. I'll warn you that
this is the first time I've edited a man page or generated a patch, so
it could be wrong / incomplete.
By the way, I think you may have misinterpreted my tone in previous
comments, I was trying to make a strong case for the program working in
the way I expected it to from reading the man page, not trying to tell
you how it should work in general. Having said that I still personally
consider a 'safety catch' on the root filesystem would be a good idea.
Thanks,
Pat

Hey Pat,

Thanks for the patch!

There are some guidelines for submitting patches in the kernel sources
under Documentation/SubmittingPatches.  Please give that a quick read:
I think it will help you.  (read: it will help us get your patch in
faster)

I tend to agree.  It really sucks that someone had to drive out to the
site to get things working again.  Not a great situation.
		  ^^ Do you need a newline there?

		     xfs_freeze suspends
		^^^^^^^ This displays without spaces between.  e.g butsinceLinuxKernelVersion2.

I think this history lesson was more appropriate in the notes section of the manpage.

Not sure you need 'up to and including the mount-point'?

Ok.

I think this is all you need, just make it bold?

That's pretty wordy... do we really need all that?

Could you clean those up and repost?  If not we'll figure something out
eventually.  ;)

Thanks again,
       Ben

Hi, here's version 2.
I read the kernel patch info , but I'm mostly running off
http://www.debian.org/doc/manuals/maint-guide/modify.en.html
Thanks for your help.

Pat