On 2018-01-30 14:50, Tomasz Pala wrote:
On Tue, Jan 30, 2018 at 08:46:32 -0500, Austin S. Hemmelgarn wrote:
I personally think the degraded mount option is a mistake as this
assumes that a lightly degraded system is not able to work which is false.
If the system can mount to some working state then it should mount
regardless if it is fully operative or not. If the array is in a bad
state you need to learn about it by issuing a command or something. The
same goes for a MD array (and yes, I am aware of the block layer vs
filesystem thing here).
The problem with this is that right now, it is not safe to run a BTRFS
volume degraded and writable, but for an even remotely usable system
Mounting read-only is still better than not mounting at all.
Agreed, but what most people who are asking about this are asking for is
to have the system just run missing a drive.
For example, my emergency.target has limited network access and starts
ssh server so I could recover from this situation remotely.
with pretty much any modern distro, you need your root filesystem to be
writable (or you need to have jumped through the hoops to make sure /var
and /tmp are writable even if / isn't).
Easy to handle by systemd. Not only this, but much more is planned:
http://0pointer.net/blog/projects/stateless.html
It's reasonably easy to handle even in a normal init system. The issue
is that most distros don't really support it well. Arch and Gentoo make
it trivial, but they let you configure storage however the hell you
want. Pretty much everybody else is mostly designed to assume that /var
is a part of /, they mostly work if it's not, but certain odd things
cause problems, and you have to go through somewhat unfriendly
configuration work during install to get a system set up that way (well,
unfriendly if you're a regular user, it's perfectly fine for a seasoned
sysadmin).
Also, slightly OT, but has anyone involved in the development described
in the article you linked every looked beyond the typical Fedora/Debian
environment for any of the stuff the conclusions section says you're
trying to achieve? Just curious, since NixOS can do almost all of it
with near zero effort except for the vendor data part (NixOS still
stores it's config in /etc, but it can work with just one or two files),
and a handful of the other specific items have reasonably easy ways to
implement them that just aren't widely supported (for example, factory
resets have at least three options already, OverlayFS (bottom layer is
your base image, stored in a read-only verified manner, top layer is
writable for user customization), BTRFS seed devices (similar to an
overlay, just at the block level), and bootable, self-installing,
compressed system images).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
