Bug#694624: /usr/sbin/xfs_freeze: freezes under lying (root)

Bug#694624: /usr/sbin/xfs_freeze: freezes under lying (root)

[Pat Emblen]

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.

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

Bug#694624: /usr/sbin/xfs_freeze: freezes under lying (root)

[Dave Chinner]

On Mon, Dec 03, 2012 at 10:31:08AM +1100, Pat Emblen wrote:
> 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.

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

> - The docs all strongly imply that it operates on mountpoints, so
> surely not many people
> would have diliberately used it on general paths?"

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

>         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?!

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...

> - 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?

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

> - At the very least I would expect it to require a 'force' option if
> it was going to freeze
> the root system.

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.
-- 
Dave Chinner
david@fromorbit.com

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

Bug#694624: /usr/sbin/xfs_freeze: freezes under lying (root)

[Pat Emblen]

 > 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

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

Bug#694624: /usr/sbin/xfs_freeze: freezes under lying (root)

[Dave Chinner]

On Tue, Dec 04, 2012 at 10:53:56AM +1100, Pat Emblen wrote:
> > 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,

Patches to fix the documentation are welcome...

> and perhaps use
> 'filesystem' rather than 'xfs' consistently.

>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.


> > 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.

Sure. Patches are welcome. ;)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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