[opensuse] Re: [opensuse-factory] Heads-Up: New Partitioning & firewall/sshd defaults on the way
On 18/11/2018 20.16, Richard Brown wrote:
On Sun, 18 Nov 2018 at 20:11, Carlos E. R. <> wrote:
On 16/11/2018 16.46, Richard Brown wrote:
On Fri, 16 Nov 2018 at 16:44, Robert Munteanu <rombert@apache.org> wrote:
- By default we will NOT propose a separate /home partition
Just to restate, does that mean that /home will end up being backed by a btrfs filesystem by default?
Correct, /home will be a btrfs subvolume
Ok, question then: If one is installing to a previously installed machine with this setup, will the home subvolume be left intact, with all its data, and only the "system" space formatted or erased?
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.
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. 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.
Like always, anyone ignoring this advice will at least be notified in the partitioning screen of the installer what is happening to their existing partitions before anything happens.
Juan Erbes was not: see his recent post. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
On Sun, 18 Nov 2018 at 20:53, Carlos E. R. <robin.listas@telefonica.net> 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).
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.
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 - 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. 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.
Like always, anyone ignoring this advice will at least be notified in the partitioning screen of the installer what is happening to their existing partitions before anything happens.
Juan Erbes was not: see his recent post.
Until I see a bug report with logs to the contrary, my opinion is that Juan's story is likely one of user error before product error. I've seen YaST warn me too robustly too often to have strong doubts of it's ability in this area. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 18 Nov 2018 20:03:13 +0100 Richard Brown <RBrownCCB@opensuse.org> wrote:
On Sun, 18 Nov 2018 at 20:53, Carlos E. R. <robin.listas@telefonica.net> 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
Le 18/11/2018 à 20:03, Richard Brown a écrit :
Users should be using it and should not be reinstalling from scratch. I do not think we should optimise for this edge case.
did you notice that if you do so you may always have a separate /home? simply because it was recommended for years and so prone to be the way the old system works? One reason I most always do a fresh install is this: be able to use the new things of the new version... and by the way if I have an ext4 root, I need a fresh install to change to btrfs anyway I never did notice it was now recommended to have only one partition, good I read this thread thanks jdd -- http://dodin.org -- 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. <robin.listas@telefonica.net> 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 11/19/18 7:27 AM, Anton Aylward wrote:
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.
I read Richard Brown's comments and thought, "How odd that someone with his level of expertise would go off down that path", then I read the rest of the thread and came across Anton's post, which pretty much sums up my sentiments. Richard is certainly entitled to his opinion for, like noses, everyone has one and most of them smell. He just needs to keep in mind that some of us have a deep seated distrust of those "greatest things since sliced bread" that come out of software development, be it programs or OSes, which comes from years of experience dealing with the vagaries of same. I think I will continue managing my systems with the same philosophy that has served me so well for the past 30 something years. Fred -- 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)
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 :-) jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
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 jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 19 Nov 2018 20:18:49 +0100 "jdd@dodin.org" <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 20.49, Dave Howorth wrote:
On Mon, 19 Nov 2018 20:18:49 +0100 "jdd@dodin.org" <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
I used ";-)" ;-)
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...
Indeed. The case I saw was when 15.0 was Beta, so I don't remember the details. I know that I was very much surprised. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
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 18/11/2018 20:03, Richard Brown wrote:
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).
Then you are not considering the bigger picture here, which you need to do. *SUSE is not a majority, monoculture or dominant player in its space; and Linux is not the dominant OS in the field where *SUSE offers products. Therefore we should act like it, not like a monopolist or would-be monopolists such as Microsoft, Apple or even Red Hat.
Many people are wrong, I'd rather we optimise to support the ones who are right.
To quote Mr Spock, "logic clearly dictates that the needs of the many outweigh the needs of the few". What is best for most users is what to optimise for, _not_ what is better for any subgroup; rightness or wrongness does not enter into it.
And with snapshots enabled I consider your above to be redundant
Relying on a particular feature of a particular non-mainstream FS with notable issues is a bad idea. It doesn't matter what that feature (or FS) is.
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.
Until I see a bug report with logs to the contrary, my opinion is that Juan's story is likely one of user error before product error.
The cause does not matter; the correct choice is to identify what made it easy to pick the incorrect path, and make sure it is not easy to choose incorrectly.
I've seen YaST warn me too robustly too often to have strong doubts of it's ability in this area.
*its And never blindly trust in tech to get you out of trouble. доверять, но проверить. Trust, but verify. -- 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 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 Tue, 20 Nov 2018 at 11:50, Carlos E. R. <robin.listas@telefonica.net> 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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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. - -- 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----- iQIzBAEBCAAdFiEEeNZxWlZYyNg7I0pvkm4MJhv0VBYFAlvz8MAACgkQkm4MJhv0 VBaA0RAAwlcsa/JCdpufboVv4pBxl91Zi/KZUHTwFfoYehaicfgo39FfTl6QR/f4 LbhnFoCZghMug+GpJVXP5tLkJ77RhHuqnfliG8dYI2DCJFo3pu37msUjA2ZLLoLj GZhQQYjj1lzieWTz2x6RYrAO0xKgynHSJygzU2V4+4PiMh7txdd1luuA3HlYF9Uo sA4dr0jgJtLFkQCcWS30+lQgU6Hq18pk+NddbkToHMsHYYyydDx4PofpzaygNTmG ShE4uA+HodoEZgGHf425/qH+NaXMaYdj/muzRIsh/BuSVjTJUOUbHGjAyVET6lzt +h5LH46BsUZr7KZp4I4Ik36rd7WPGGrcBQ323wPpbaluc7LGg3Rfs0cFvjhnBOb5 mtHttJJxxdry1NOB15vpaKGOftHvEnlavBqK+urzhDnz7icynMRTCx+N99XQ4B1m WinhAIlb6Ht9+5zype9Z7vS3y0HuUc1HSYucUty+wZTrP6p44xlVypPVZcBE3ztk BYZCNc5UVDegaFCQVlRIRU46twmh+eDze7C9Ed4VS1xU5eBO3hVf9rXWVhF+GLd/ KBsKavYqd6EG3whARVukEHQABZvd5gPiDr83dW+/vIlBKCgUNCMqK/pxrQhQHGaO fZ1FID+ONPj9/NOfUKI3iZiFwpJT+FHzdmRzhKK7OU/DKcGFDwk= =Rivk -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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 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 '/'. Good grief Charlie Brown. (with openSuSE playing the role of Lucy jerking the football away....) -- David C. Rankin, J.D.,P.E.
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))
Op dinsdag 20 november 2018 00:11:49 CET schreef David C. Rankin:
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 '/'.
Good grief Charlie Brown. (with openSuSE playing the role of Lucy jerking the football away....) Tone down, please. Or step up and come up with good proposals and help work on it.
-- 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
-----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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 18/11/2018 20:44, 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.
Agreed.
You may think so, and I do, but many people do not agree.
^ This.
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.
Precisely. It is not only for upgrades. It also facilitates: * backup and restore * performance optimisation (OS on SSD, home on disk) * repair, troubleshooting, data recovery, etc. * multi-boot between different versions of a distro * multi-boot between different distros * arguably, multi-boot between different OSes
Juan Erbes was not: see his recent post.
Exactly. - -- 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----- iQIzBAEBCAAdFiEEeNZxWlZYyNg7I0pvkm4MJhv0VBYFAlvz4hQACgkQkm4MJhv0 VBbV+RAAgTtXtdNRA44+GzuDRVFUwgsY+HJhxiANCnV7q3Uyjypzf+kHSE1pOahX Bx0PhTfRYgn171d8cOgVM/0GPTDslGsifoTNsTlG+z1HJH4K0DlXYxjKLDsunBfK ye4FJIotP5VE8gig2mrimpZdfBiofO41vcjuznuUWSqJimfmE7OSf0vPQrwldI1+ KOvMRLWA5EKE2K2gZH6Y3WkFd+dgHOtuox+iSniq/TdzT8VPMPhuETbAt9DuBN/R k/8ZYkZ+IH3wIkH2y4XzKm3FbKN5TOKYnzuR8KKjxHHQWAebOKd7C2tnuhJDNoxP o+q/JDzHLWJdgUURTGgKOGRETsy/MVHsDBSnhTq/xcrCunj6PzVLmnxxnpt8Bh9Q XMqJ+371gjEvFTCenmmsgDT1+CSKEeH8YAOiNFJrG28nJNHw3v5i8fCmQYmemvQe yBOe2rgdaL9+pouZxVDiea9fUMnmhxWCoQNn/0VA94bKJJAZFm2Jvzpk7vjUyz6A J5DX6t9ZnFIaIpkTnOS0T10yR/PJX0Hfu7SpnMxOu0RPKp97cyCx4HejPEJMWdBS w50KaXqpOTBzx7+WMGA6OWnLcYUJFYIVUP18T7ZhEXQ5PaIGQLhvM3iyU87HOKyp iq0haJHrxkgTbT20g7odzY7W7nd84smV6n6D8UAY0RwbsfiT38s= =WeMD -----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 <lproven@suse.cz> 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 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. The best backup method is a totally separate copy of the data on other media in another computer, and then filesystem is irrelevant.
* 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.
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.
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.
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. -- 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 Tue, 20 Nov 2018 at 11:44, Liam Proven <lproven@suse.cz> 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 20/11/2018 11:49, Richard Brown wrote:
That's fine, I don't care for your opinion either the second you supported the personal attack against me.
It is not a "personal attack against" you if people think you are wrong and tell you so, Richard. -- 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 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
Le 20/11/2018 à 11:37, Richard Brown a écrit : (...) I disagree on most of your statements... but wont discuss this here because I don't want to be part of a "Richard Bashing" that is irrelevant (I'm pretty sure you don't take all these decisions alone). However, I guess having only one partition for the hole system will make much less frequent the "space unavailable" problem that hit my BTRFS machine every two weeks... 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 11.37, Richard Brown wrote:
On Tue, 20 Nov 2018 at 11:29, Liam Proven <lproven@suse.cz> 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 Tue, 20 Nov 2018 at 11:57, Carlos E. R. <robin.listas@telefonica.net> 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.
* 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. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 20/11/2018 12.00, Richard Brown wrote:
On Tue, 20 Nov 2018 at 11:57, Carlos E. R. <robin.listas@telefonica.net> 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)
On Tue, 20 Nov 2018 at 12:05, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 20/11/2018 12.00, Richard Brown wrote:
On Tue, 20 Nov 2018 at 11:57, Carlos E. R. <robin.listas@telefonica.net> 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.
No, it isn't. My original mail went through repeatedly explaining how users can customise it, request a separate /home, grow their swap, or otherwise change the profile from the default, which is changing. Anyone who thinks I said more or other than that clearly didn't read my original mail.
You are wrong. btrfs restore does that just fine.
Care to show the re-create btrfs structure wiki page somewhere?
it's unnecessary if you use btrfs restore 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/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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
On Tue, 20 Nov 2018 at 12:24, jdd@dodin.org <jdd@dodin.org> wrote:
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 :-(
YaST does the job just fine, but Carlos wanted to do it manually, so Carlos can -- 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 <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:09, Richard Brown пишет:
You are wrong. btrfs restore does that just fine.
Care to show the re-create btrfs structure wiki page somewhere?
it's unnecessary if you use btrfs restore
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/
There is not a single occurrence of "btrfs restore" on this page. -- 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 à 18:32, Andrei Borzenkov a écrit :
"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
it's probably btrfs send and btrfs receive 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 à 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:
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.
Yes, that's one step further :-)
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.
Right.
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?
You can not. In fact, arguably you can not upgrade from Leap 42.x to Leap 15.x when using btrfs on "/", because its layout has changed. Now, if there were a tool that would create a btrfs partition with all the needed subvolumes automatically, in the layout (with corresponding fstab prototype) needed for each specific openSUSE release... Even a script... things would be a bit different. -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
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
Le 20/11/2018 à 12:43, Liam Proven a écrit :
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.
yes - but not a file system, only a folder
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.
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
That works too. In fact I normally make it an NTFS drive so I can share my data directories with Windows too.
there are problems copying files between linux and ntfs (incompatible characters in names) but he whole thing is the same for you and me, only variants of 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: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
participants (11)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
Dave Howorth -
David C. Rankin -
jdd＠dodin.org -
Knurpht-openSUSE -
Liam Proven -
Richard Brown -
Rodney Baker -
Stevens