Debian Bug report logs - #694624
/usr/sbin/xfs_freeze: freezes under lying (root) filesystem if mountpoint is not currently mounted

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Patrick Emblen <support@talbragar.com.au>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: /usr/sbin/xfs_freeze: freezes under lying (root) filesystem if mountpoint is not currently mounted

Date: Thu, 29 Nov 2012 00:43:42 +1100

Package: xfsprogs
Version: 3.1.7+b1
Severity: important
File: /usr/sbin/xfs_freeze

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.



-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xfsprogs depends on:
ii  libblkid1     2.20.1-5.1
ii  libc6         2.13-33
ii  libreadline5  5.2-11
ii  libuuid1      2.20.1-5.1

xfsprogs recommends no packages.

Versions of packages xfsprogs suggests:
ii  acl      2.2.51-8
pn  attr     <none>
pn  quota    <none>
pn  xfsdump  <none>

-- no debconf information

Message #10 received at submit@bugs.debian.org (full text, mbox, reply):

From: Christoph Hellwig <hch@infradead.org>

To: Patrick Emblen <support@talbragar.com.au>, 694624@bugs.debian.org

Cc: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Re: Bug#694624: /usr/sbin/xfs_freeze: freezes under lying (root) filesystem if mountpoint is not currently mounted

Date: Fri, 30 Nov 2012 11:04:42 -0500

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?

Message #20 received at 694624@bugs.debian.org (full text, mbox, reply):

From: Pat Emblen <support@talbragar.com.au>

To: 694624@bugs.debian.org

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

Date: Mon, 03 Dec 2012 10:31:08 +1100

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.

Message #25 received at 694624@bugs.debian.org (full text, mbox, reply):

From: Dave Chinner <david@fromorbit.com>

To: Pat Emblen <support@talbragar.com.au>, 694624@bugs.debian.org

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

Date: Tue, 4 Dec 2012 08:48:33 +1100

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

Message #30 received at 694624@bugs.debian.org (full text, mbox, reply):

From: Pat Emblen <support@talbragar.com.au>

To: 694624@bugs.debian.org

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

Date: Tue, 04 Dec 2012 10:53:56 +1100

> 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

Message #35 received at 694624@bugs.debian.org (full text, mbox, reply):

From: Dave Chinner <david@fromorbit.com>

To: Pat Emblen <support@talbragar.com.au>, 694624@bugs.debian.org

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

Date: Tue, 4 Dec 2012 13:15:11 +1100

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

Message #40 received at 694624@bugs.debian.org (full text, mbox, reply):

From: Pat Emblen <talcom@talbragar.com.au>

To: 694624@bugs.debian.org

Subject: freezes under lying (root) - patch

Date: Thu, 06 Dec 2012 15:56:47 +1100

[Message part 1 (text/plain, inline)]

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

[update-man-xfs_freeze.patch (text/x-patch, attachment)]

Message #45 received at 694624@bugs.debian.org (full text, mbox, reply):

From: Ben Myers <bpm@sgi.com>

To: Pat Emblen <talcom@talbragar.com.au>, 694624@bugs.debian.org

Subject: Re: Bug#694624: freezes under lying (root) - patch

Date: Thu, 6 Dec 2012 14:22:57 -0600

Hey Pat,

On Thu, Dec 06, 2012 at 03:56:47PM +1100, Pat Emblen wrote:
> A patch for the man page is (hopefully) attached.

Thanks for the patch!

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

Ok, I'll go easy on you then.  ;) 

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)

> Having said that I still personally consider a 'safety catch' on the
> root filesystem would be a good idea.

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.

> Description: Updates to the man page to more accurately describe the
>  behaviour of the program.
> Forwarded: not-needed
> Bug-Debian: http://bugs.debian.org/694624
> Author: Patrick Emblen <support@talbragar.com.au>
> --- a/man/man8/xfs_freeze.8
> +++ b/man/man8/xfs_freeze.8
> @@ -1,16 +1,17 @@
>  .TH xfs_freeze 8
>  .SH NAME
> -xfs_freeze \- suspend access to an XFS filesystem
> +xfs_freeze \- suspend access to a freezable filesystem
>  .SH SYNOPSIS
>  .B xfs_freeze \-f
>  |
>  .B \-u
> -.I mount-point
> -.fi
> -.SH DESCRIPTION
> -.B xfs_freeze
> -suspends and resumes access to an XFS filesystem (see
> -.BR xfs (5)).
> +.I path.fi
> +.SH DESCRIPTION.B xfs_freezesuspends and resumes access to compatible filesystems.
		  ^^ Do you need a newline there?

		     xfs_freeze suspends
> +The command was originaly specific to the XFS filesystem (see
> +.BR xfs (5))but since Linux kernel version 2.6.29, the interface which
		^^^^^^^ This displays without spaces between.  e.g butsinceLinuxKernelVersion2.

> +XFS uses to freeze and unfreeze has been elevated to the VFS, so that
> +this tool can now be used on many other Linux filesystems.
> +The root filesystem is not treated in any special way and may also be frozen.

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

>  .PP
>  .B xfs_freeze
>  halts new access to the filesystem and creates a stable image on disk.
> @@ -19,15 +20,14 @@
>  that support the creation of snapshots.
>  .PP
>  The
> -.I mount-point
> -argument is the pathname of the directory where the filesystem
> -is mounted.
> -The filesystem must be mounted to be frozen (see
> -.BR mount (8)).
> +.I path
> +argument is the path to any directory within the mounted filesystem up to and including
> +the
> +.I mount-point.

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

>  .PP
>  The
>  .B \-f
> -flag requests the specified XFS filesystem to be
> +flag requests the specified filesystem to be

Ok.

>  frozen from new modifications.
>  When this is selected, all ongoing transactions in the filesystem
>  are allowed to complete, new write system calls are halted, other
> @@ -55,16 +55,23 @@
>  must be supplied to
>  .BR xfs_freeze .
>  .SH NOTES
> -A copy of a frozen XFS filesystem will usually have the same universally
> +.BR xfs_freeze
> +treats the root filesystem the same as any other filesystem.

> +Take great care to verify that the path you specify contains the filesystem
> +you intend to freeze and is not for example, an empty mount-point.

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

> +If you inadvertently freeze the root filesystem you should immediately
> +unfreeze it with the
> +.B \-u
> +option.  If you attempt any action that tries to write to the frozen filesystem
> +your shell can be blocked waiting for the write and in most cases you will
> +not be able to open another shell to run the unfreeze command.
> +.PP
> +A copy of a frozen filesystem will usually have the same universally 

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

>  unique identifier (UUID) as the original, and thus may be prevented from
>  being mounted.
> -The XFS
> +For XFS filesystems, the
>  .B nouuid
>  mount option can be used to circumvent this issue.
> -.PP
> -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.
>  .SH SEE ALSO
>  .BR xfs (5),
>  .BR lvm (8),

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

Thanks again,
       Ben

Message #50 received at 694624@bugs.debian.org (full text, mbox, reply):

From: Pat Emblen <talcom@talbragar.com.au>

To: 694624@bugs.debian.org

Subject: PATCH freezes under lying (root)

Date: Sat, 08 Dec 2012 01:24:48 +1100

[Message part 1 (text/plain, inline)]

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

[update-man-xfs_freeze.patch (text/x-patch, attachment)]

Send a report that this bug log contains spam.