On Sun, 18 Nov 2018 20:03:13 +0100 Richard Brown wrote:

On Sun, 18 Nov 2018 at 20:53, Carlos E. R. wrote:

...

Then I'm afraid that we must advise people to install the traditional way with a separate /home partition, not a subvolume.

I do not see the sense, at all, to advise users to use a seperate /home partition to facilitate an upgrade approach which we do not recommend, document, consider in our packaging and tooling, nor test (or in other words..support).

One of the longstanding reasons for using linux, and before that unix, is that one is not tied to a particular school of thought, but is rather instead offered a toolkit to apply to one's own circumstances to the best of one's ability and knowledge.

...

...

We have had seamless in place upgrade via both the media-based "Upgrade" workflow and the online "zypper dup" workflow for well over a decade now

Users should be using it and should not be reinstalling from scratch. I do not think we should optimise for this edge case.

You may think so, and I do, but many people do not agree.

Many people are wrong, I'd rather we optimise to support the ones who are right.

Optimise by all means but not at the expense of making the system brittle towards alternative possible ways of proceeding. Ultimate optimisation of infrequent events such as upgrades is not important.

...

In fact, I always install with a separate "/home" partition in order to be able to do just that: format "/" during fresh install if/when needed leaving "/home" with all my valuable data intact. I almost always upgrade instead, but if the upgrade crashes beyond repair, it is nice to have the alternative.

And with snapshots enabled I consider your above to be redundant

And there you go; optimising too far already. Perhaps the user is not using a filesystem that is capable of snapshots, or for whatever reason has chosen not to enable them. Unless of course you are saying that it is compulsory to use a snapshot-capable filesystem with snapshots enabled? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/11/18 02:03 PM, Richard Brown wrote:

On Sun, 18 Nov 2018 at 20:53, Carlos E. R. wrote:

...

Then I'm afraid that we must advise people to install the traditional way with a separate /home partition, not a subvolume.

I do not see the sense, at all, to advise users to use a seperate /home partition to facilitate an upgrade approach which we do not recommend, document, consider in our packaging and tooling, nor test (or in other words..support).

Years ago I made the joking observation: "BtrFS - the One File System To Rule Them All", meaning all rives, all partitions ... everything.. So now you are telling us that is not a joke. *EVERYTHING*. You've made it clear, elsewhere, Richard, that for BtrFS even /boot should be part of The One File System. I'm not sure if you would want to make SWAP part of it too, but I can see how that, too, would be logical. (And you could exclude it from snapshots, couldn't you?) Carlos again:

...

In fact, I always install with a separate "/home" partition in order to be able to do just that: format "/" during fresh install if/when needed leaving "/home" with all my valuable data intact. I almost always upgrade instead, but if the upgrade crashes beyond repair, it is nice to have the alternative.

Some of us are a bit more paranoid about our DATA; some of us might think that even snapshots are inadequate insurance. Some of us put our data on other physical volumes, devices, more aggressive backups, even directly into the cloud. Some of us partition aggressively what is under /home. Or under something else. Developers are often cautioned to snapshot to revision control regularly, aggressively, to make small changes and test them. and RCS/VC at each change. I'm well aware that Snapper can be told to snapshot a folder at aggressive - one minute - intervals, but I think this is a bit wrong-headed and an abuse of the mechanism. Snapshots like that are not the same.

And with snapshots enabled I consider your above to be redundant - if the upgrade goes wrong I can always boot to a read-only snapshot from before the upgrade and rollback that way. In an absolute worse case where absolutely nothing works (which really, would be a tier of breakage I've never seen from openSUSE or SLE, despite my luck at seeing horrific breakages) users still have the option of booting to live media, chroot the disk in question, and rollback that way.

I disagree. Maybe its the way I make backups (or learnt the had way to do so) but the !FAIL!-ures I've had are not 'finger trouble' but catastrophic hardware, usually disk drive, problems. And lets get realistic about this, Richard, disk failure is way, way the most common failure mode in computing (apart from 'finger trouble'). It has always been why we run backups to other media, take them off site. Sorry, all you say about BtrFS just increases my paranoia towards it. It screams to me "Single Point of Failure!" Make that four exclamation marks.

We should optimise our distribution for the tools and workflows we have today and which we actively build, test, and support. We shouldn't have defaults chosen to facilitate inadvisable bad habits left over from a bygone age.

Calling doing regular backups, to other media, off site, "bad habits" is plain insulting. And yes, I know, you consider the IT managers and executives that consider such to be Good, if not "Best" practice to be 'dinosaurs', and due for extinction. You may have the sense not to say that to their faces but there it is' implicit, an emergent property of the stance you are taking in thread.

I've seen YaST warn me too robustly too often to have strong doubts of it's ability in this area.

Ah. You trust programmers. I've been one. I've been one for military-grade s/w and had to get past tests and testers like you would not believe, that would reduce people I've interviewed to tears (and have!). I don't trust my own code that made it past those reviews. And the youth, the commercial pressures ... sorry, I don't trust programmers and I think that it is foolish on your part to do so. Do I trust backup software? No, I don't trust backup software either, that's why I verify by doing restores from backup regularly. There's a Schrödinger's Cat law of backups. Until you 'open the box' and do the restore, the backup is in an indeterminate state. That's why I recognise that 'archiving a project' is not the same as a backup, and that's why I think the the backup-by-snapshot is not suitable for a lot of the work I and others do. Archiving, even RCS, is not the same as backups. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 19/11/2018 14.27, Anton Aylward wrote:

On 18/11/18 02:03 PM, Richard Brown wrote:

...

...

I've seen YaST warn me too robustly too often to have strong doubts of it's ability in this area.

Ah. You trust programmers. I've been one. I've been one for military-grade s/w and had to get past tests and testers like you would not believe, that would reduce people I've interviewed to tears (and have!). I don't trust my own code that made it past those reviews. And the youth, the commercial pressures ... sorry, I don't trust programmers and I think that it is foolish on your part to do so.

Do I trust backup software? No, I don't trust backup software either, that's why I verify by doing restores from backup regularly.

There's a Schrödinger's Cat law of backups. Until you 'open the box' and do the restore, the backup is in an indeterminate state.

That's why I recognise that 'archiving a project' is not the same as a backup, and that's why I think the the backup-by-snapshot is not suitable for a lot of the work I and others do. Archiving, even RCS, is not the same as backups.

Yes, I have seen YaST format the /home partition without warning. I may have written bugzillas about that. Yes, YaST did say in the middle of a list of things that it was going to format this or that partition. Not prominently that it was going to format /home. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 19/11/2018 18.24, jdd@dodin.org wrote:

Le 19/11/2018 à 15:25, Carlos E. R. a écrit :

...

Yes, YaST did say in the middle of a list of things that it was going to format this or that partition. Not prominently that it was going to format /home.

it probably couldn't know it was home :-)

The label said "home", IIRC ;-) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On Mon, 19 Nov 2018 20:18:49 +0100 "jdd@dodin.org" wrote:

Le 19/11/2018 à 20:02, Carlos E. R. a écrit :

...

On 19/11/2018 18.24, jdd@dodin.org wrote:

...

...

it probably couldn't know it was home :-)

The label said "home", IIRC ;-)

a label is just that, a label and it may not be a good idea to name it home, just in case you can have more than one home on the computer

anyway, not sure yast read anything such

No, more useful would be to read /etc/fstab. Or examine the running system. But a highlighted warning if any heuristic suggested it might be /home would seem useful... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 19/11/2018 14.27, Anton Aylward wrote:

...

On 18/11/18 02:03 PM, Richard Brown wrote: ...

...

...

I've seen YaST warn me too robustly too often to have strong doubts of it's ability in this area.

Ah. You trust programmers. I've been one. I've been one for military-grade s/w and had to get past tests and testers like you would not believe, that would reduce people I've interviewed to tears (and have!). I don't trust my own code that made it past those reviews. And the youth, the commercial pressures ... sorry, I don't trust programmers and I think that it is foolish on your part to do so.

Do I trust backup software? No, I don't trust backup software either, that's why I verify by doing restores from backup regularly.

There's a Schrödinger's Cat law of backups. Until you 'open the box' and do the restore, the backup is in an indeterminate state.

That's why I recognise that 'archiving a project' is not the same as a backup, and that's why I think the the backup-by-snapshot is not suitable for a lot of the work I and others do. Archiving, even RCS, is not the same as backups. Yes, I have seen YaST format the /home partition without warning. I may have written bugzillas about that.

Yes, YaST did say in the middle of a list of things that it was going to format this or that partition. Not prominently that it was going to format /home. Bet /home's partition was included. I have ( in > 100 installs ) never seen

Op maandag 19 november 2018 15:25:55 CET schreef Carlos E. R.: the installer format /home without notice. -- Gertjan Lettink a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 20/11/2018 11.36, Liam Proven wrote:

On 18/11/2018 20:03, Richard Brown wrote:

...

We should optimise our distribution for the tools and workflows we have today and which we actively build, test, and support. We shouldn't have defaults chosen to facilitate inadvisable bad habits left over from a bygone age.

STRONGLY disagree. In fact, the reverse is true.

What enabled Linux to thrive, as opposed to rivals such as *BSD, is "optimising" (to use your word) for interoperability, compatibility, and playing well with others.

THAT is the path to choose. Always.

Indeed! -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 20/11/2018 11.55, Richard Brown wrote:

On Tue, 20 Nov 2018 at 11:50, Carlos E. R. <> wrote:

...

On 20/11/2018 11.36, Liam Proven wrote:

...

On 18/11/2018 20:03, Richard Brown wrote:

...

...

We should optimise our distribution for the tools and workflows we have today and which we actively build, test, and support. We shouldn't have defaults chosen to facilitate inadvisable bad habits left over from a bygone age.

STRONGLY disagree. In fact, the reverse is true.

What enabled Linux to thrive, as opposed to rivals such as *BSD, is "optimising" (to use your word) for interoperability, compatibility, and playing well with others.

THAT is the path to choose. Always.

Indeed!

The day that someone who supports this opinion pulls a finger out and actually does the work to make that viewpoint remotely true, instead of constantly opining on mailniglists, is the day I will agree with that sentiment.

Until then, my view will continue to be shaped by the work I do, and the work done by those others contributors.

Which means, we'll continue to focus the distribution on the tools and workflows we have today. We'll support that which we maintain, that which we test, that which we support. We won't necessarily rule out alternatives, but people should be clear exactly where the distributions attentions, efforts, and contributions are focused on.

Which is the goal of my thread. I'm open to suggestions that better achieve the goals I set-out in my original post, but screams for "do more, support more, cover all my personal edge cases to that same level of quality" will not be heeded by me.

I'm not opposed to others doing that work though. So please, shut up and step up.

I will NOT shut up. I will recommend every person that asks to install a separate /home. The same as I advise people about btrfs advantages and problems. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 20/11/2018 12.32, Liam Proven wrote:

On 20/11/2018 12:02, Carlos E. R. wrote:

...

I will NOT shut up.

...

I will recommend every person that asks to install a separate /home.

...

The same as I advise people about btrfs advantages and problems.

Well said, Carlos. I agree on all points.

Oh, I'm fair. I tell them that btrfs has wonderful advantages, like being able to reboot to a previous snapshot. :-) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 20/11/2018 00.11, David C. Rankin wrote:

On 11/18/2018 01:44 PM, Carlos E. R. wrote:

...

...

...

A common manner of installing the next release is to replace "/" and leave "/home" partition intact. No it will not Then I'm afraid that we must advise people to install the traditional way with a separate /home partition, not a subvolume.

Do not TOUCH my partitions, do NOT make then the way you think they should be. They are MY partitions. I determine what they are, not you.

It is totally bass-ackwards logic to try and move users /home to a BRTFSK'ed up '/'.

Calm down, they are not moving your home, it affects only new installs defaults. Only make sure that it doesn't try to format your separate /home, and that it doesn't create a /home subvolume either. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas))

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 20/11/2018 00:11, David C. Rankin wrote:

Do not TOUCH my partitions, do NOT make then the way you think they should be. They are MY partitions. I determine what they are, not you.

It is totally bass-ackwards logic to try and move users /home to a BRTFSK'ed up '/'.

Good grief Charlie Brown. (with openSuSE playing the role of Lucy jerking the football away....)

This. Bonus for the splendid imagery. :-) - -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEeNZxWlZYyNg7I0pvkm4MJhv0VBYFAlvz49MACgkQkm4MJhv0 VBaovw//aU+QEjA8JVArjNba8uxP7+Nvq1bNqjxj6chxJZ0m8cdtYWw+S5IhbyeB CU3ovdpIolv05K6AVGrK9H+R7mCc4WAusgIhIlz5lpr2ktCbJjOZOhepawJs2yRV wNIho46VMun78EMK+XT2R6DogUqbi0MjghRuEcYw+xybIdW+fMNd3CSryEUuIOGc 9B0AqPBnVsP1cdCRpk31xkk05cV/p4canhS5UBAcUjQyBRS3hiSV3c5C6ZinVT6j c4VqWSCQs9q02Ed8n3TVigXWvmnh4zFG3ODxH0SnNaUNtd5Sp2bWGNaKBZ/VtUuo 6QY3au72D5LanBDNUjeYa1igkHXMKMJSfaqET/xL08ykWpdDlzUzb0IPglzF+Ww+ VGGd682EEZwmco7sKzxMKM/SmIsi8O7TYxteQa0JG88J2FKrNXUupBbUObac4LAB k3jTwNpX1nay1D7E9U5PYSPwf8wccjQh1rxZOIKr9oJW8uSahk1llJAm3a0Srnem ndV4Nwfr6QCzpGaoLpllTWP9jnJ7i6khPBTG5fNyarykwOzc7BdShLIx1t8rUBsA +AGKypRDZsWIugRvDT9Je9geRjtgY2zse7n6bir3H4fmRS8yQRfpC/hF3eCuL9DH egonYzR7yxxTVSclWxNsRRNt57Zx47cbG2fyyrjTZSAr2YhfX5A= =Fron -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 20 Nov 2018 at 11:29, Liam Proven wrote:

Precisely.

It is not only for upgrades. It also facilitates: * backup and restore

Backup and restore is best served by using btrfs' incremental backup features

* performance optimisation (OS on SSD, home on disk)

This is not true, the current behaviour of our partitioner does NOT support OS on SSD and /home on disk

* repair, troubleshooting, data recovery, etc.

Having a single filesystem is bar far easier to repair, troubleshoot, and recover data from. Speaking from experience, having to worry about half a dozen partition boundries when recovering data from a broken hard disk is an absolute nightmare

* multi-boot between different versions of a distro * multi-boot between different distros * arguably, multi-boot between different OSes

All of which are fine reasons for users who care about those use cases to click the tickbox to have a separate /home But none of those are valid as the 'default' usecase for openSUSE - we don't support installing multiple versions of the distro alongside each other, nor do we support parallel user of /home from multiple distros - no way your /home dotfiles will be kept sane in those cases. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 20 Nov 2018 at 11:44, Liam Proven wrote:

On 20/11/2018 11:37, Richard Brown wrote:

...

Backup and restore is best served by using btrfs' incremental backup features

Piffle. You do *not* get to dictate to anyone what FS they use or what backup methodology.

Actually, I do, because I'm a linux distribution engineer and that's exactly what we do You should understand the role and purpose of a Linux distribution when it comes to setting defaults..aren't you responsible for documenting them?

The best backup method is a totally separate copy of the data on other media in another computer, and then filesystem is irrelevant.

Please investigate btrfs specific functions like send/receive and their relevance to incremental backup, and then tell me the "filesystem is irrelevant" Until then, I will simply say your view is incomplete and your conclusion is fundamentally wrong.

...

This is not true, the current behaviour of our partitioner does NOT support OS on SSD and /home on disk

Don't care.

That's fine, I don't care for your opinion either the second you supported the personal attack against me. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tuesday, 20 November 2018 21:14:15 ACDT Liam Proven wrote:

On 20/11/2018 11:37, Richard Brown wrote:

...

Backup and restore is best served by using btrfs' incremental backup features Piffle. You do *not* get to dictate to anyone what FS they use or what backup methodology.

Agreed. Opinions are one thing (and can be heeded or ignored), but dictating to users how things SHALL be done is the domain of M$ and Apple, not Linux.

The best backup method is a totally separate copy of the data on other media in another computer, and then filesystem is irrelevant.

Completely agreed.

...

...

* performance optimisation (OS on SSD, home on disk)

This is not true, the current behaviour of our partitioner does NOT support OS on SSD and /home on disk

Don't care.

Secondly, it should. This is an absolutely basic scenario; otherwise you are assuming that everyone has expensive kit or an unlimited budget. Rotating media are still much cheaper than SSD and probably will be for as long as Linux is around.

Again, spot on! I have / on SSD, /home on a RAID10 array on rotating rust, along with a separate RAID10 array for bulk data, separate partitions for / downloads, /usr/local, /var, /root and /boot. (Yes, I'm old school, but I prefer to have those partitions separate for multiple reasons). Oh, and /tmp, /dev and /run are RAM disks, not physical partitions.

...

Having a single filesystem is bar far easier to repair, troubleshoot, and recover data from. Speaking from experience, having to worry about half a dozen partition boundries when recovering data from a broken hard disk is an absolute nightmare

Hi. Professional systems engineer since the 1980s here.

Essentially every single part of that statement is wrong.

Yes, it is. Build resilience and fault-tolerance into the system using redundancy and a failed disk simply becomes an annoyance, not a recovery exercise. Use the right RAID levels and multiple failed disks can be tolerated. Modern, large capacity disks seem to have become less reliable (in some variants and some batches); I've had to have disks replaced under warranty more than once, and never have I lost data because of it.

...

All of which are fine reasons for users who care about those use cases to click the tickbox to have a separate /home

It is a profound error to optimise for any one particular use case.

Be flexible, not rigid. Remember Postel's law.

Yes!

...

But none of those are valid as the 'default' usecase for openSUSE - we don't support installing multiple versions of the distro alongside each other, nor do we support parallel user of /home from multiple distros - no way your /home dotfiles will be kept sane in those cases.

What we "support" does not enter into this.

This is the community distro. Questions of what any organisation supports are for paid support contracts and the enterprise distros they serve.

It is not a community distro's place to try to impose anything on anyone.

Defaults are one thing. Saying "don't do that because we don't support it" is entirely another.

Thanks for speaking up, Liam. Absolutely right! -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 20/11/2018 11.37, Richard Brown wrote:

On Tue, 20 Nov 2018 at 11:29, Liam Proven wrote:

...

Precisely.

It is not only for upgrades. It also facilitates: * backup and restore

Backup and restore is best served by using btrfs' incremental backup features

...

* performance optimisation (OS on SSD, home on disk)

This is not true, the current behaviour of our partitioner does NOT support OS on SSD and /home on disk

It certainly does. This computer is done that way, for instance.

...

* repair, troubleshooting, data recovery, etc.

Having a single filesystem is bar far easier to repair, troubleshoot, and recover data from. Speaking from experience, having to worry about half a dozen partition boundries when recovering data from a broken hard disk is an absolute nightmare

No, I can not agree. It is impossible, AFAIK, to recover from scratch a btrfs based computer, from backup alone. It has to be formatted and a bunch of subvolumes has to be created. There is no automated method I know of that can extract the structure of an existing btrfs filesystem and recreate it. And you forget that one method of recovery is to format "/" and install again, because the data is safe on "/home".

...

* multi-boot between different versions of a distro * multi-boot between different distros * arguably, multi-boot between different OSes

All of which are fine reasons for users who care about those use cases to click the tickbox to have a separate /home

Yes. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

On 20/11/2018 12.00, Richard Brown wrote:

On Tue, 20 Nov 2018 at 11:57, Carlos E. R. wrote:

...

On 20/11/2018 11.37, Richard Brown wrote:

...

...

This is not true, the current behaviour of our partitioner does NOT support OS on SSD and /home on disk

It certainly does. This computer is done that way, for instance.

No way, no how, YaST did that by default. You must have chosen the second device manually for /home..and none of my suggestions will prevent you from doing that in the future. I'm only talking about changing the defaults, not your ability to do whatever the hell you want with your disks.

That's different from what you said initially.

...

...

...

* repair, troubleshooting, data recovery, etc.

Having a single filesystem is bar far easier to repair, troubleshoot, and recover data from. Speaking from experience, having to worry about half a dozen partition boundries when recovering data from a broken hard disk is an absolute nightmare

No, I can not agree.

It is impossible, AFAIK, to recover from scratch a btrfs based computer, from backup alone.

It has to be formatted and a bunch of subvolumes has to be created. There is no automated method I know of that can extract the structure of an existing btrfs filesystem and recreate it.

You are wrong. btrfs restore does that just fine.

Care to show the re-create btrfs structure wiki page somewhere? -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)

Le 20/11/2018 à 12:09, Richard Brown a écrit :

But if someone wants to make such a wiki page, a copy/paste of this CC-BY-SA blog post wouldn't be a bad start https://rootco.de/2018-01-19-opensuse-btrfs-subvolumes/

I read this (and not for the first time). I guess you dont expect most people to follow this page manually? don't yast do the job? what I call "documentation" is not that kind :-( jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 20/11/2018 à 12:25, Richard Brown a écrit :

On Tue, 20 Nov 2018 at 12:24, jdd@dodin.org wrote:

...

don't yast do the job?

what I call "documentation" is not that kind :-(

YaST does the job just fine, but Carlos wanted to do it manually, so Carlos can

ok, thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

20.11.2018 14:00, Richard Brown пишет:

...

...

...

* repair, troubleshooting, data recovery, etc.

Having a single filesystem is bar far easier to repair, troubleshoot, and recover data from. Speaking from experience, having to worry about half a dozen partition boundries when recovering data from a broken hard disk is an absolute nightmare

No, I can not agree.

It is impossible, AFAIK, to recover from scratch a btrfs based computer, from backup alone.

It has to be formatted and a bunch of subvolumes has to be created. There is no automated method I know of that can extract the structure of an existing btrfs filesystem and recreate it.

You are wrong. btrfs restore does that just fine.

"btrfs restore" has absolutely nothing to do with restoring from backup. Did you bother to actually look at manual page for it? btrfs-restore - try to restore files from a damaged btrfs filesystem image -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 20/11/2018 à 11:57, Carlos E. R. a écrit :

And you forget that one method of recovery is to format "/" and install again, because the data is safe on "/home".

well, that is a bit of a simplification. /home do not hold only user data, it holds also application metadata (configs, some logs...) that can't be safely shared between distros, even distro versions. So What I do and advise most people to do at least on personal computers (=used mostly by only one people) is to have root (/), /home and some sort of /data. Only /data holds really data, that is text files, photos, videos... and should have it's own partition. in this context, having / and /home on the same partition is perfectly correct an I do it often. I also seems to remember a mail exchange where it was said that BTRFS can mirror itself to an other disk as sort of backup. I'm also pretty sure that most of this discussion could be avoided if the features where correctly shared and documented, preferably on the openSUSE wiki (or btrfs one, not on Arch one). And this can only be done by people that make the changes as nobody else knows what happen. For example, Richard states that BTRFS can make incremental backup much better. I trust him. But how, where is the doc? Is this page still uptodate (one year old) https://btrfs.wiki.kernel.org/index.php/Incremental_Backup ? One year ago I gave up using it. for years openSUSE set root as btrfs and /home as XFS, and it's my present config for at least 3 years (was before leap). I don't see how I can change it without a fresh install? thanks jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 20/11/2018 12:15, jdd@dodin.org wrote:

well, that is a bit of a simplification.

/home do not hold only user data, it holds also application metadata (configs, some logs...) that can't be safely shared between distros, even distro versions.

This is not true. /home is a filesystem. It is not any user's home directory. That is /home/$something. The *purpose* of /home is to be shared by multiple users, each with their own subdirectory. The complete path often should not be shared, that is correct. But so long as each version or distro has different user account names, sharing /home is perfectly fine. E.g. I append the initials of the distro or desktop to the username -- so "liamu" for Ubuntu, "liamf" for Fedora, "liams" for openSUSE. Then those 3 very different distros share the same /home partition perfectly happily.

So What I do and advise most people to do at least on personal computers (=used mostly by only one people) is to have root (/), /home and some sort of /data.

Only /data holds really data, that is text files, photos, videos... and should have it's own partition.

That works too. In fact I normally make it an NTFS drive so I can share my data directories with Windows too.

in this context, having / and /home on the same partition is perfectly correct an I do it often.

It works. I strongly prefer the flexibility of having it elsewhere. When I came back to the SUSE world last year, I found the default filesystems (btrfs for /, XFS for /home) a little odd and they caused me problems with dual-booting with Ubuntu, but fair enough, openSUSE's choices have long been unusual - I remember when it defaulted to ReiserFS. At least it defaulted to a separate /home which I regarded as far more important than it what it was formatted as, and still do. Later I discovered that I could not shrink an XFS volume to add a 2nd distro to a particular machine, which was a pain, but not critical. -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 20/11/2018 12:58, jdd@dodin.org wrote:

yes - but not a file system, only a folder

OK, yes, that is correct. But normally a filesystem too on a competently-administered multiuser host machine. :-)

I see this as unnatural, but if it fits your needs... and with different distros in the same /home, managing users permissions and groups can be complicated

One of the problems of the PC architecture is that it's a de-facto standard. It just evolved out of lots of companies doing their own thing and pulling in different directions. Other systems are far more tightly-governed. On SUN boxes, for instance, SUN and a small handful of licensed companies governed how stuff worked. Original Apple 680x0 Macs were a single-company game and didn't really support other OSes at all. PowerPC Macs were gradually opened up, first because of the licensing programme, then because PC industry kit got good enough, so gradually, PowerMacs got industry-standard PCI slots, industry-standard EIDE disk controllers, USB ports, memory slots, etc. and lost all their proprietary Apple ports and expansion slots. There used to be a fairly strict mechanism for PC partitioning, applied and followed by DOS, OS/2, Windows 3.x and 9x and NT. 1 primary partition per drive, and these were enumerated first; then 1 extended partition, with logical drives in that. Most non-MS operating systems ignored it and did their own thing inside a primary partition (of which PCs only supported 4 per disk). Most non-MS OSes remained marginal and most died off. Linux went "fair enough, we will play" and used the MS partitioning scheme and never introduced its own -- it had its own _disk formats_, sure, but inside DOS/Windows-style partitions. The BSDs never learned this lesson and they never got as far as Linux did. Now, GPT is making all this irrelevant. Unfortunately, GPT goes hand-in-hand with UEFI, and the FOSS world has been largely excluded from UEFI. A few big enterprise vendors paid and got their kernels signed. Free distros are out in the cold. Getting a free non-enterprise Linux distro booting on a UEFI-only machine with GPT disks remains hard.

there are problems copying files between linux and ntfs (incompatible characters in names)

It can happen. I don't use Maildir, so it has never really affected me. I would not keep /home on NTFS but symlinking Documents, Pictures, Videos, Downloads etc. from an NTFS volume into a home directory on /home/$username seems to work very well. Not so with Dropbox any more, unfortunately. :-( -- Liam Proven - Technical Writer, SUSE Linux s.r.o. Corso II, Křižíkova 148/34, 186-00 Praha 8 - Karlín, Czechia Email: lproven@suse.com - Office telephone: +420 284 241 084 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org