[Nix#9417] Nix should not `mount -o remount,rw` #98

New issue

Open

opened 2024-03-16 06:44:53 +00:00 by lix-bot · 0 comments

lix-bot commented

2024-03-16 06:44:53 +00:00

Member

Upstream-Issue: NixOS/nix#9417

Can anybody explain why this is here?

516e7ddc41/src/libstore/local-store.cc (L576-L578)

I traced it back to b9124a5c33. It looks like the original codepath would check if /nix/store was a --bind mount and act only in that specific situation.

The comment says:

516e7ddc41/src/libstore/local-store.cc (L565-L566)

Note that this codepath gets hit not only for the /nix/store store, but also when you use nix copy --from /mnt/somewhere/nix/store. For example when recovering from a mangled system and trying to copy off whatever can be salvaged. Why would the --from store need to be remounted read-write for that to happen?

Some filesystems, in particular btrfs, will react to serious problems by switching the filesystem to readonly mode, and interpret any subsequent mount -o remount,rw as a "I know what I'm doing" signal by the root user. I don't think it's a good idea for nix-daemon to signal this unilaterally. Remounting read-write without doing an fsck first is usually a bad decision, and bad decisions should be left up to the humans :)

I think this behavior (remount read-write without an fsck) is one of the two reasons why Nixfolk have such strange (and strong!) opinions about btrfs. The other reason is explained in https://github.com/NixOS/nix/pull/7126#issuecomment-1820045768. I'd hate to see the same thing happen with bcachefs.

Upstream-Issue: https://git.lix.systems/NixOS/nix/issues/9417 Can anybody explain why this is here? https://github.com/NixOS/nix/blob/516e7ddc41f39ff939b5d5b5dc71e590f24890d4/src/libstore/local-store.cc#L576-L578 I traced it back to b9124a5c336fd231adaa548cf5be311731847848. It looks like the original codepath would [check if `/nix/store` was a `--bind` mount](https://github.com/NixOS/nix/commit/b9124a5c336fd231adaa548cf5be311731847848#diff-766e649c52f1b2f334ad2788aa2230b88b0a7cdd2799529c6125462960b145e0R430-R440) and act only in that specific situation. The comment says: https://github.com/NixOS/nix/blob/516e7ddc41f39ff939b5d5b5dc71e590f24890d4/src/libstore/local-store.cc#L565-L566 Note that this codepath gets hit not only for the `/nix/store` store, but also when you use `nix copy --from /mnt/somewhere/nix/store`. For example when recovering from a mangled system and trying to copy off whatever can be salvaged. Why would the `--from` store need to be remounted read-write for that to happen? Some filesystems, in particular btrfs, will react to serious problems by switching the filesystem to readonly mode, and interpret any subsequent `mount -o remount,rw` as a "I know what I'm doing" signal by the root user. I don't think it's a good idea for `nix-daemon` to signal this unilaterally. Remounting read-write without doing an fsck first is usually a bad decision, and bad decisions should be left up to the humans :) I think this behavior (remount read-write without an fsck) is one of the two reasons why Nixfolk have such strange (and strong!) opinions about btrfs. The other reason is explained in https://github.com/NixOS/nix/pull/7126#issuecomment-1820045768. I'd hate to see the same thing happen with bcachefs.

lix-bot added the

bug

imported

labels 2024-03-16 06:44:53 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/lix#98

No description provided.

[Nix#9417] Nix should not mount -o remount,rw #98

[Nix#9417] Nix should not `mount -o remount,rw` #98