Future Storage Layout

[lordfolken]

This is currently a placeholder for the storage layout discussion.

[lordfolken]

/home partition.

• indepdendent of system partition /
• should survive an upgrade even with a new image
• should enlarge itsefl at boot to fill a certain percentage of the storage device.

[MaxKellermann]

I'd be very happy not to give Windows users access, because that complicates things - but the discussion on #156 about it did not lead to a final decision about it. If it is decided that Windows compatibility is not desired, we pick, of course, ext4.

But in any case, the contents of that data partition need to be "stable", as in: if you replace the root+boot partition with a new (or older?) version, there must not be any problems. No "oops there's a .bashrc which is not compatible with the new image version" and no "this ~root home folder does not contain files required by the new version".
This needs to "just work".
Therefore, designing this data partition properly now and documenting it now, before we start having it, is important. All of its contents must be explicit design, not "let's just mount this on /home and stuff starts landing there".

[lordfolken]

Actually if we do this clever, we could mount an usbstick on the userdata directory, and run directly from the stick.

Although i might have some reservations when we append log files and mount the stick synchronosly.

[kedder]

USB sticks are flimsy, I'd not trust a usb-socket in flight :)

[mihu-ov]

The "runnning from USB drive" discussion is a regular one, like watching Dinner for Two on new years eve ;-)
I think we already have a consensus on this. If anyone of the experts wants to do it he probably knows the limitations and risks. If we support that for the standard user there will be data loss, frustration and an exploding XCSoar forum.

[mihu-ov]

Once installed in a glider physical access to the µSD card is a real pain. That´s why I think other than bench testing there is no real use case for accessing the data partition from Windows. Easy options for data transfer from USB drive, smartphone, etc, are more important.

[MaxKellermann]

Sub-thread: what data really needs to be on the data partition?

• XCSoarData
• but what else?

Any other configuration or user data?

Machine-specific configuration is on the boot partition, not data, where it will be accessible by u-boot (config.uEnv, e.g. display rotation). This will be overwritten with a new image; but we could have a shadow copy on the new data partition, to be moved over on the first boot, so those settings are preserved?

[mihu-ov]

WiFi passwords are probably the only sensitive data I could think of.

[MaxKellermann]

this is not about security [...] For me, this is about correctness.

Let's not forget why it is considered a good practice to run things as unprivileged user. It is exclusively because this approach provides some additional security protections. All these different users and permissions exists only to prevent someone else (logged on the system) from messing with your sensitive data.

This discussion cannot possibly be conclusive or even lead anywhere if you ignore my statement explaining what this is not about, and then say this is only about exactly that. Even after citing the very statement you ignored, the one you contradicted with.

[lordfolken]

The main reason is and has always been: to protect the os from the application.
For example:

• The diskspace for the root user is usally reserved 10%. So even if the app fills the disk, the os can still boot and proceed.
• The priortiy level can be overruled by an operating system process. So even if the app is consuming all cpu, the os is still responsive.
• No critical files can be damaged, by a fat finger or a bug in the app trying to write somewhere. (we have had such cases in xcsoar.)

The whole idea is that as long the box is there, the situation can be remidiated. If its dead, another level of interference is necessary.

[August2111]

Ideally that partition contains just an XCSoarData folder (instead of .xcsoar), like on most other XCSoar machines (Android, Kobo, and previously WinCE).

This I prefere: A uniform name for all distris also in Linux: XCSoarData...
And what I really want: If a user put his sd card in a Windows PC he can can easely cleanup this folder on this without any moving to another device! Maybe I'm a little bit old school for all developer here - but this it's real live on the airfields! Of course it is easier to handle a linux format like ext4 - but I also want to compare with other varios and so on.
It is also possible to split it in two folders, one for cache and logging - and another one for the data, saved flights and settings - but this makes additional work too.
As Max already explained: Certain settings cannot be easily transferred to an (external) folder - such as the display, touchscreen, wifi settings and more. And of course it would be very nice if these were retained after an update / new image...

[MaxKellermann]

As Max already explained: Certain settings cannot be easily transferred to an (external) folder - such as the display, touchscreen, wifi settings and more. And of course it would be very nice if these were retained after an update / new image...

No, I did not say that. We can put anything we want on the data partition, but it must be an explicit decision with an explicit design. We can do that, and of course we should do that. No setting any (regular) user ever changes must be lost. The root partition should ideally be mounted read-only (for regular users).

Power users can, of course, have a writable root partition and hack everything - but a new firmware image will lose all of that. And yes, they can do opkg upgrades if they want and have a opkg server, instead of applying a whole new firmware image (but I do not want to support that).