Scratch PR for comments #1
Conversation
|
Rendered draw.io diagram: |
There was a problem hiding this comment.
Added some minor comments.
It may be good to capture any other scenarios to the lower layer, (other than the addition of objects, if they exist) and how those could be handled by the local-overlay.
And as for the future work, it may be necessary to add a functionality to move from a local-overlay to the regular local store. I believe the store "copy" operation would be relatively straightforward to implement.
| > In the store object state diagram diagram, this is represented by the fact that there are two green nodes, instead of just one like the one blue node. | ||
|
|
||
| This introduces some flexibility in the system: the same "logical" layered store can be represented in multiple different "physical" configurations. | ||
| This isn't a problem *per se*, but does mean there is a bit more complexity to consider during testing and system administration. |
There was a problem hiding this comment.
It would be good to have some elaborations on what the complexity increase will be.
Could a situation happen, where the user could end up "using" from the lower-layer, without having an entry in overlay db?
There was a problem hiding this comment.
If the system-admin does a mistake on remounting, and mounts a different lower layer, is there any way to detect it during init()?
or things will blow up in runtime?
The answer to this may be obvious, but I dont know so just confirming
There was a problem hiding this comment.
It would be good to have some elaborations on what the complexity increase will be.
Could a situation happen, where the user could end up "using" from the lower-layer, without having an entry in overlay db?
Part of my vagueness is that I suspect there is some ambiguity I haven't thought of.
Could a situation happen, where the user could end up "using" from the lower-layer, without having an entry in overlay db?
That at least I don't think can happen.
There was a problem hiding this comment.
If the system-admin does a mistake on remounting, and mounts a different lower layer, is there any way to detect it during init()?
or things will blow up in runtime?
The "fsck" thing would catch it, but I fear it will be slow enough that it shouldn't be run unconditionally.
There was a problem hiding this comment.
Could a situation happen, where the user could end up "using" from the lower-layer, without having an entry in overlay db?
Here I was trying to refer to a situation where a user does a wrong thing, like copy a dir from one system to another, which refer to some nix store paths.
Doing such a thing on other nix stores would cause it to fail, but it would likely "work" in this case. Or it might fail in unexpected manner, if these copied nix-store links are used to do some nix commands by the user.
This isn't a big problem, but it still is a case of non "normal" behaviour.
The "fsck" thing would catch it, but I fear it will be slow enough that it shouldn't be run unconditionally.
This isn't an important issue at the moment, could be ignored..
* Update the RFC process documentation - Nudge authors towards using Semantic Line Breaks for writing the RFC text - Nudge authors towards posting their text as pre-RFC in the forum first - Tweak wording around who declares FCP slightly - Make clear that the shepherds have to announce FCP, and when exactly the period officially starts - Be more open about when to do the implementation work relative to the RFC, and reflect the current practice of starting implementation work early - Make more clear that RFCs should not be amended, and that important information should live e.g. in documentation instead. * RFC template: Use semantic line breaks Given the short text this may not make a huge difference, but given that every RFC starts with a copy of that template, the hope is that it will nudge people to continue writing in that style. * RFC template: Add "Prior art" section This is mostly inspired by Rust's RFC template. Also added a couple of words to the "Alternatives" section, similarly inspired by Rust's template. * fixup! Update the RFC process documentation * fixup! Update the RFC process documentation Co-authored-by: 7c6f434c <7c6f434c@mail.ru> * fixup! Update the RFC process documentation Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io> --------- Co-authored-by: 7c6f434c <7c6f434c@mail.ru> Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Co-authored-by: Ryan Mulligan <ryan@ryantm.com> Co-authored-by: Connor Brewster <cbrewster@hey.com> Co-authored-by: Ben Radford <benradf@users.noreply.github.com> Co-authored-by: Divam <dfordivam@protonmail.com>
Ericson2314
force-pushed
the
local-overlay-store
branch
from
fa72f1c
to
04e4b56
Compare
|
NixOS#152 This is now an official (proposed) RFC! |
No description provided.