]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit - contrib/unbound/libunbound/python/doc/examples/example1b.rst
MFV r328229:
authorAlexander Motin <mav@FreeBSD.org>
Sun, 21 Jan 2018 23:49:17 +0000 (23:49 +0000)
committerAlexander Motin <mav@FreeBSD.org>
Sun, 21 Jan 2018 23:49:17 +0000 (23:49 +0000)
commit226cd471b4f70b704481c2537f1e6185ba1bcf8d
tree1bcdc8747edc18ab5632164d67b36f9ae21cde6f
parent272f833cde1fa8604b2b06433303c63dca031ea8
parentdbee84cc27849f5395ac74706c50c0e7eaf49376
MFV r328229:
8930 zfs_zinactive: do not remove the node if the filesystem is readonly

illumos/illumos-gate@93c618e0f4932dc0bb9a9c90d8c4a5d029de5797

https://www.illumos.org/issues/8930:
We normally remove an unlinked node when its last user goes away and the
node becomes inactive. However, we should not do that if the filesystem
is mounted read-only including the case where it has its readonly
property set. The node will remain on the unlinked queue, so it will
not be leaked.

One particular scenario is when we receive an incremental stream into a
mounted read-only filesystem and that stream contains an unlinked file
(still on the unlinked queue). If that file is opened before the
receive and some time later after the receive it becomes inactive we
would remove it and, thus, modify the read-only filesystem. As a
result, the filesystem would diverge from its source and further
incremental receives would not be possible (without forcing a rollback).

Another related scenario, that may or may not be possible depending on an
OS / VFS policy, is when an open file is unlinked, then the filesystem is
remounted read-only, and then the file is closed.

Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Approved by: Gordon Ross <gwr@nexenta.com>
Author: Andriy Gapon <avg@FreeBSD.org>
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_znode.c