Hi,
It would be really great if ext4 supported an xfs_freeze like operation.
On xfs it spared me a lot of headaches when I was playing with unstable
kernel features.
thanks
Gabor
[note: I'm not subscribed. Please Cc: me if answering]
Hi, team:
This is a very cool feature. Is there any planing or schedule on it ?
Coly
在 2007-01-25四的 18:28 +0100，Vitez Gabor写道：
> Hi,
>
> It would be really great if ext4 supported an xfs_freeze like operation.
> On xfs it spared me a lot of headaches when I was playing with unstable
> kernel features.
>
> thanks
> Gabor
>
> [note: I'm not subscribed. Please Cc: me if answering]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Vitez Gabor wrote:
> Hi,
>
> It would be really great if ext4 supported an xfs_freeze like operation.
> On xfs it spared me a lot of headaches when I was playing with unstable
> kernel features.
>
> thanks
> Gabor
>
Right now ext3 and ext4 -can- be frozen, but only via devicemapper,
because the call to freeze_bdev is only exposed via
<dm ioctl>
dev_suspend
do_suspend
dm_suspend
lock_fs
freeze_bdev <-- generic, exported kernel function
on an lvm volume. So, I think ext[34] are perfectly capable of being
frozen, there's just no generic userspace utility to point at a generic
block device to do that freezing. xfs's collection of ioctls to do this
directly got grandfathered in, I guess. :)
-Eric
On Thu, Jan 25, 2007 at 01:40:58PM -0600, Eric Sandeen wrote:
> on an lvm volume. So, I think ext[34] are perfectly capable of being
> frozen, there's just no generic userspace utility to point at a generic
> block device to do that freezing. xfs's collection of ioctls to do this
> directly got grandfathered in, I guess. :)
xfs's collection of ioctls do the right thing if the program which
freezes the filesystems exits without unfreezing the filesystem
(closing the file descriptor used by the freeze ioctl should unfreeze
the filesystem, I hope)? And I assume that if a setuid program which
freezes filesystems forgets to catch SIGTSTP, and a hostile user types
^Z at the wrong time, that's considered a buggy setuid program? :-)
One of the reasons why direct exposire to the freeze routines was
always considered a little dangerous, and my guess is that's why we
don't have a first class VFS interface. Then again, XFS managed to
get an exemption from some of the standard kernel merging rules,
including allowing the IRIX compatibility layer, and I'm guessing the
xfs collection of ioctls snuck in that way too. :-)
- Ted
Theodore Tso wrote:
> On Thu, Jan 25, 2007 at 01:40:58PM -0600, Eric Sandeen wrote:
>> on an lvm volume. So, I think ext[34] are perfectly capable of being
>> frozen, there's just no generic userspace utility to point at a generic
>> block device to do that freezing. xfs's collection of ioctls to do this
>> directly got grandfathered in, I guess. :)
>
> xfs's collection of ioctls do the right thing if the program which
> freezes the filesystems exits without unfreezing the filesystem
> (closing the file descriptor used by the freeze ioctl should unfreeze
> the filesystem, I hope)? And I assume that if a setuid program which
> freezes filesystems forgets to catch SIGTSTP, and a hostile user types
> ^Z at the wrong time, that's considered a buggy setuid program? :-)
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 didn't mean to imply that it was better or worse, just that those xfs
ioctls went in back when ioctls weren't getting quite so much scrutiny.
And it provided the freeze functionality for a linux filesystem at a
time when there weren't other options.
Having the lvm tools do this automatically through generic layers during
snapshot is absolutely a much nicer, cleaner way to go when snapshotting.
> One of the reasons why direct exposire to the freeze routines was
> always considered a little dangerous, and my guess is that's why we
> don't have a first class VFS interface. Then again, XFS managed to
> get an exemption from some of the standard kernel merging rules,
> including allowing the IRIX compatibility layer, and I'm guessing the
> xfs collection of ioctls snuck in that way too. :-)
>
> - Ted
I prefer to think of it as a portability layer... :)
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?
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... heck I can issue BLKROSET ioctls too, and that's arguably a
lot more dangerous, because it's going to come as a big surprise to the
filesystem, rather than a coordinated freeze.
-Eric
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
On Fri, Jan 26, 2007 at 08:10:13PM -0500, Theodore Tso wrote:
> 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....
I personnaly use xfs_freeze to get a bit of extra protection from filesystem
corruption would suspend-to-disk or suspend to ram go wrong. Read-only
remount is not an option because X is running, etc..
Gabor