public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Vitez Gabor <vitezg@niif.hu>, linux-ext4@vger.kernel.org
Subject: Re: support freeze operation like xfs_freeze
Date: Fri, 26 Jan 2007 20:10:13 -0500	[thread overview]
Message-ID: <20070127011013.GB9897@thunk.org> (raw)
In-Reply-To: <45BA7F5A.5000703@redhat.com>

On Fri, Jan 26, 2007 at 04:23:22PM -0600, Eric Sandeen wrote:
> xfs_freeze is actually -designed- to exit without unfreezing the 
> filesystem, FWIW, for better or worse.  And I suppose there is all sorts 
> of mayhem that could stem from setuid programs of all stripes...

I had a vague memory of that, but I probably supressed the horror.  :-)

> But anyway, on a less OT-topic, it has always seemed a little weird to 
> me that you can -only- freeze a filesystem on an lvm block device. 
> Surely there are occasionally legitimate reasons to freeze a filesystem 
> on an arbitrary block device, if the filesystem can support it?

The issue isn't that you can only freeze a filesystem on an LVM block
device; in fact, you can't.  You can only take a snapshot on an LVM
block device.  I wish you could take snapshots on arbitrary block
devices --- the EVMS1 kernel patches allowed that --- but
unfortunately they were implemented in a way that the kernel community
decided was too ugly to let live, or at least merge into mainline.

> I don't see how direct exposure to freezing routines via LVM ioctls is 
> any less dangerous than direct exposure to freezing routines on 
> /dev/hda1... 

So the issue is that you *don't* have direct expusire to the freezing
routines via LVM ioctl's.  All you can do is request a snapshot, and
the LVM ioctl's freeze the filesystems, take the snapshot and then
unfreeze the filesystem.  

You're right that the BLKROSET ioctls are probably just as dangerous
as well, and of course root can do all sorts of things like running
mkfs, or dd'ing into /dev/kmem, etc.  I think though the issue was
that someone requested a user mode program that was accessible via a
shell script, probably because XFS had that functionality, and the
concern was that few people trusted system administrators to be able
to handle such power responsibly.  Freezing the filesystem for hour or
minutes seems like a very bad idea, and that's exactly the sort of
thing that I can imagine a clueless level one system administrator
doing.  ("I know!  I'll freeze the filesystem while I backup all 30 TB
of it, and then I'll unfreeze it.")

The question really is what are the legimate uses of such a facility
where you wouldn't be better off taking a snapshot and then doing the
backup dump on the snapshot?  The real issue is that we can't take
snapshots on plain block devices, but that might be the better problem
to solve....

						- Ted

  reply	other threads:[~2007-01-27  1:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-25 17:28 support freeze operation like xfs_freeze Vitez Gabor
2007-01-25 17:59 ` coly
2007-01-25 19:40 ` Eric Sandeen
2007-01-26 21:22   ` Theodore Tso
2007-01-26 22:23     ` Eric Sandeen
2007-01-27  1:10       ` Theodore Tso [this message]
2007-01-29  9:57         ` Vitez Gabor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070127011013.GB9897@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=vitezg@niif.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox