On 2012/10/09 23:55, Jan Kara wrote:
On Tue 09-10-12 18:46:26, Fernando Luis Vazquez Cao wrote:
Regarding your concern about the ioctl approach, when a frozen
filesystem is detached from the namespace it can still be reached
through the block device it is sitting on (well... with the exception
of btrfs which has some issues that I am working on) and this is the
reason I added a block device level check ioctl too. That said, if one
day we have a filesystem which is not block device based and supports
fsfreeze (ioctl_fsfreeze() returns -EOPNOTSUPP if the superblock has
no ->freeze_fs operation, which is the case for all virtual
filesystems and NAS drivers that we have) the two check ioctls would
not cover that case.
In principle, there are filesystems which operate e.g. on MTD and thus do
not have a block device. So far none of these seem to support freezing but
in principle there's no reason they couldn't. And for these filesystems your
ioctls won't help.
Such devices fall in category 1) below, which means they would
be automatically thawed on umount if frozen. As long as the
filesystem remains mounted the check ioctl can be used.
I think that to cover all cases without adding a completely new API we
need to do the following:
1) Filesystems which are not tied to a block device (virtual
filesystems, NAS, etc):
As soon as the filesystem is removed from the namespace the
superblock based fsfreeze ioctls become useless; if we let a umount
of a frozen filesystem succeed we would not be able to thaw it (well
we could use emergency thaw but it would be overkill). Since we do
Actually, you can always mount the filesystem again (you will essentially
just attach the superblock to the namespace again) and thaw the filesystem.
So this is not a big issue.
The problem is that we may generate write I/O during the second
mount. We would need to audit all filesystems (which I am fine
with if there is a sensible use case).
not want to break lazy umounts the only viable solution is thawing
the superblock automatically on umount (releasing the active
reference taken in freeze_super() to be more precise).
I'm not against this. As you write below, you cannot really thaw
freeze coming via block device so you end up with somewhat inconsistent
behavior (thaw only freezes by ioctl) but after all freeze of a filesystem
and freeze of a block device *are* somewhat different requests so the
inconsistency can be justified.
Do I get right that when we do this, you won't need ioctls for querying the
freeze state?
I would still want the check ioctls. For example, in some cases the
freeze/unfreeze process is controlled by a daemon which can die
and with the current API there is no way to check what state
filesystems where left in (well, we have emergency thaw but thaw
unfreezes all filesystems which may not be what we want, i.e. overkill).
I have heard a lot of complaints about this from users.
Virtualization is a special case of this where the freeze of a guest
filesystem can be initiated from the hypervisor and carried out by
a guest agent behind the guest's administrator's back.
2) Block device based filesystems:
These can be reached through the block device it is sitting on even
if the filesystem was detached from the namespace and have the
particularity that they can be frozen using two different APIs, a
block device level one and the ioctls. When a filesytem was frozen
using the former, which only has in-kernel users such as dm,
automatically thawing the filesystem on umount is arguably too rude
(we can end up breaking the filesystem level consistency of a
storage snapshot). It we care about this, we could modify
sys_umount() so that filesystem is automatically thawed if and only
if there are no block device level freezes active. This behavior
would be consistent with case 1) above (the premise here is that
both fsfreeze and umount are userspace controlled operations and the
administrator should know what it is doing) and is the less likely
to cause surprises to freeze_bdev() users.
It would also be nice to have a block device level thaw ioctl for
emergency cases (for example, a scenario where thaw_bdev() was not
called and the freeze counter was left in a inconsistent state;
freeze_bdev() and thaw_bdev() are exported symbols and in many cases
we cannot control what external modules do).
Umm, I don't know. I'd rather forbid thawing via ioctl when the device is
frozen via block device so that should solve possible issues caused by
buggy userspace and the rest is a kernel bug - emergency thaw is for
that...
That is an approach I myself considered and that I would be ok
with. I guess I will implement both and let Al decide.
Thanks,
Fernando
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
