option to mount read-only subvolume with read-write access

option to mount read-only subvolume with read-write access

[Eric Levy]

At times it is helpful to modify a subvolume to which has been assigned 
a read-only property, without changing the property. One reason for 
keeping the property is that the same subvolume may be reachable 
through another mount point. Another is to ensure that the property 
persists even if some operation fails to complete.

Would you consider adding a mount option to cause the system to ignore 
a read-only property for the subvolume accessed through the mount 
point, without affecting access to the same subvolume through other 
mount points?

Re: option to mount read-only subvolume with read-write access

[David Sterba]

On Thu, Nov 10, 2022 at 05:12:52AM -0500, Eric Levy wrote:
> At times it is helpful to modify a subvolume to which has been assigned 
> a read-only property, without changing the property.

So that would be a silent change in the subvolume and not detectable by
eg. checking the generation. That would break incremental send at least
and goes against the point of read-only subvolume. If you'd want to do a
silent change it would have to be something that does not need to
copy-on-write any block (that requires generation change) so it would
have to be in-place and with recalculated checksum.

> One reason for 
> keeping the property is that the same subvolume may be reachable 
> through another mount point. Another is to ensure that the property 
> persists even if some operation fails to complete.

Yeah but the other mount points would see the old data, depending on the
cached status of the blocks.

> Would you consider adding a mount option to cause the system to ignore 
> a read-only property for the subvolume accessed through the mount 
> point, without affecting access to the same subvolume through other 
> mount points?

I think it does not have a well defined semantics, what you ask seems to
be some kind of multi headed subvolume that could appear different
depending on the way it's accessed from the VFS mount point which is out
of reach in many cases.

I'd probably need to understand what you mean in the first sentence "At
times it is helpful", I don't have an idea where it would be helpful.

Re: option to mount read-only subvolume with read-write access

[Eric Levy]

> So that would be a silent change in the subvolume and not detectable 
> by
> eg. checking the generation. That would break incremental send at 
> least
> and goes against the point of read-only subvolume.

> Yeah but the other mount points would see the old data, depending on 
> the
> cached status of the blocks.

Perhaps a different feature would be needed, then, of a new property 
that makes a subvolume appear as read-only, at least from the 
standpoint of the VFS, when accessed through a mount point higher on 
the file tree, but not when mounted directly.

>> I think it does not have a well defined semantics, what you ask 
>> seems to
> be some kind of multi headed subvolume that could appear different
> depending on the way it's accessed from the VFS mount point which is 
> out
> of reach in many cases.

I'm not sure whether this means the same as I just wrote, or not.

> I'd probably need to understand what you mean in the first sentence 
> "At
> times it is helpful", I don't have an idea where it would be helpful.

In some scenarios, upcoming changes to a file tree, intended to become 
the default mounts in future boot sessions, will be staged in a closed 
environment, which may include use of "chroot". It is helpful for the 
subvolume to be read-write in the environment created by temporary 
mount points, but still protected from accidental modification through 
its physical location on the root tree.

Re: option to mount read-only subvolume with read-write access

[Matthew Warren]

> In some scenarios, upcoming changes to a file tree, intended to become
> the default mounts in future boot sessions, will be staged in a closed
> environment, which may include use of "chroot". It is helpful for the
> subvolume to be read-write in the environment created by temporary
> mount points, but still protected from accidental modification through
> its physical location on the root tree.

I think for that situation you'd want to make a snapshot of the
subvolume (which is currently mounted read-only) and then modify it.
You can then make the new subvolume have the name of the old
subvolume. This should allow you to keep the old data in read-only
until you reboot in which case the new data will be mounted.

Matthew Warren

Re: option to mount read-only subvolume with read-write access

[Eric Levy]

On Thu, Nov 10 2022 at 11:46:38 AM -0500, Matthew Warren 
<matthewwarren101010@gmail.com> wrote:
>>  In some scenarios, upcoming changes to a file tree, intended to 
>> become
>>  the default mounts in future boot sessions, will be staged in a 
>> closed
>>  environment, which may include use of "chroot". It is helpful for 
>> the
>>  subvolume to be read-write in the environment created by temporary
>>  mount points, but still protected from accidental modification 
>> through
>>  its physical location on the root tree.
> 
> I think for that situation you'd want to make a snapshot of the
> subvolume (which is currently mounted read-only) and then modify it.
> You can then make the new subvolume have the name of the old
> subvolume. This should allow you to keep the old data in read-only
> until you reboot in which case the new data will be mounted.
> 
> Matthew Warren

It may work as well in many cases, but one limitation is that the child 
volume must reside permanently in the target location, or some other, 
until it replaces the parent volume.

Re: option to mount read-only subvolume with read-write access

[David Sterba]

On Thu, Nov 10, 2022 at 08:50:57AM -0500, Eric Levy wrote:
> > So that would be a silent change in the subvolume and not detectable 
> > by
> > eg. checking the generation. That would break incremental send at 
> > least
> > and goes against the point of read-only subvolume.
> 
> > Yeah but the other mount points would see the old data, depending on 
> > the
> > cached status of the blocks.
> 
> Perhaps a different feature would be needed, then, of a new property 
> that makes a subvolume appear as read-only, at least from the 
> standpoint of the VFS, when accessed through a mount point higher on 
> the file tree, but not when mounted directly.
> 
> >> I think it does not have a well defined semantics, what you ask 
> >> seems to
> > be some kind of multi headed subvolume that could appear different
> > depending on the way it's accessed from the VFS mount point which is 
> > out
> > of reach in many cases.
> 
> I'm not sure whether this means the same as I just wrote, or not.
> 
> > I'd probably need to understand what you mean in the first sentence 
> > "At
> > times it is helpful", I don't have an idea where it would be helpful.
> 
> In some scenarios, upcoming changes to a file tree, intended to become 
> the default mounts in future boot sessions, will be staged in a closed 
> environment, which may include use of "chroot". It is helpful for the 
> subvolume to be read-write in the environment created by temporary 
> mount points, but still protected from accidental modification through 
> its physical location on the root tree.

This sounds like the transaction update that is in openSUSE,
https://github.com/openSUSE/transactional-update . The difference is
that you would like it to work on the same subvolume and that all the
work is done on the filesystem level, not completely managed by
userspace utilities.

Re: option to mount read-only subvolume with read-write access

[Eric Levy]

On Mon, Nov 14 2022 at 09:33:31 PM +0100, David Sterba 
<dsterba@suse.cz> wrote
>> This sounds like the transaction update that is in openSUSE,
> https://github.com/openSUSE/transactional-update . The difference is
> that you would like it to work on the same subvolume and that all the
> work is done on the filesystem level, not completely managed by
> userspace utilities.


My understanding of the TU framework is that the tools create a 
snapshot to be selected for the next boot session, and that while that 
snapshot is being prepared, its read-only property is disabled. Once 
some modification operation concludes, the read-only property is 
toggled back to true. A file-system feature would make it easier to 
alter the snapshot in some staging environment, without changing the 
snapshot properties, or the location of the snapshot in the full file 
system.

My current understanding of TU is based on some amount of 
extrapolation, however, which may be inaccurate.