On Thu, Jul 21, 2022, at 5:53 PM, Peter Boy wrote:
We decided to further discuss section 1.2 (File System and Storage
Organization) on the mailing list to prepare a final decision next
meeting.
The text on hackmd is for an unknown reason broken. Instead to spend
time to repair it I’ve transferred the text to our team page, a task we
had to do anyway.
You find the text at:
https://docs.fedoraproject.org/en-US/server-working-group/docs/server-tec...
Because it has not yet been finalized, it is not linked anywhere.
I have made some modifications to section 1.2 and taken up suggestions
from Chris.
Current tech spec file system section:
https://fedoraproject.org/wiki/Server/Technical_Specification#File_system
I propose the following change:
The default file system type for Fedora Server installs will be XFS running atop LVM for
all partitions except /boot. [1]
[2]
An option will be provided in the Fedora Server installer to enable disk encryption.
[1] Removed the second sentence because there isn't a bootloader limitation anymore.
GRUB2 supports encrypted boot partitions, but the installer doesn't configure GRUB for
booting from an encrypted boot partition. And also Boot Loader Specification effectively
proscribes it.
[2] Removed the 2nd paragraph since those discussions already happened, and resulted in
the current layout.
I am convinced that a technical specification has to include a
description and explanation of the properties and also a rationale if
they are not self-explanatory. And the storage organization is on the
one hand not self-explanatory and on the other hand one of the
distinguishing features of Fedora Server.
I admit my bias. I'm a brutal editor. Part of why is due to my experience as a
technical writer. At one time I was a fire hose. OK fine, I'm still a fire hose. But
I've come to realize not every venue is an opportunity to write for the sake of
writing.
The most successful specifications state the facts, with enough specifics to implement the
specification. A longer spec is not a better spec. Instead, refer to the original
discussions using footnotes with the archived-at list header URL provided in every Fedora
list email. The best reference for why a decision was made is the original discussion, not
a restated version of them.
A serious and genuine specification involves setting out goals and
intentions and deriving technical properties from them (and justifying
the effort involved). Otherwise, it would be a superfluous
legitimization effort and a waste of time, which I would not be willing
to do.
I agree with most of this, with particular emphasis on limiting the specification to
helping us (re)produce the edition consistently, and as a reference to test against.
Another way of putting it is, every sentence in a specification should be deliberate and
serve the reader at that moment. Permit the reader to be selfish by providing them the
least amount of information necessary to implement the spec correctly.
The text also does not restrict future flexibility (see Chris 17:7:41
UTC). In any case, we need to periodically review the techn. spec. We
really shouldn't leave it for another 8 years or so. And then Chris is
welcome to propose BTRFS as default again and maybe the technical and
organizational realities will be different than when we last discussed
it. And we are free to decide on a different rationale and
implementation. Or maybe we can keep the basic principle and only
change the implementation.
Sure.
--
Chris Murphy