Dear listmembers, dear openSUSE - maintainers, I maintain about 5 to 6 PC running (openSUSE) linux. My own, my sisters my friends ... Currently most of them are running with leap. During the last month I had to reinstall _all_ of them. All with broken / inconsitent / strange behaving root Btrfs file systems. After 25 years of working with linux I'd consider myself kind of experienced what regards linux problems. And, if that had had happened once I would have said it has been my fault. I do not think so any more. I consider Btrfs instable and inappropriate for public usage. I'd go further and would like to ask, *why* this is set as the default root fs when installing. This is totally inunderstandable to me after my experiences. I never ever experienced any bit of advantage in comparison with ext4. But I experienced nights of work - just to restore a state that had had existed a few days before. So, please, think it over: *take Btrfs out as default!* Use stable and well known systems as the foundation of public systems. Changing things only to change something is leading nowhere. Besides, if there is a kind soul that can explain what was the reason for making Btrfs the default I would highly appreciate. I cannot see any change besides significantly improved stability when going back to ext4. The latter being the most important thing IMHO. My two cents regards Dieter Jurzitza -- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday, 26 February 2017 08:22:41 CET Dr.-Ing. Dieter Jurzitza wrote:
Dear listmembers, dear openSUSE - maintainers, I maintain about 5 to 6 PC running (openSUSE) linux. My own, my sisters my friends ... Currently most of them are running with leap.
During the last month I had to reinstall _all_ of them. All with broken / inconsitent / strange behaving root Btrfs file systems.
After 25 years of working with linux I'd consider myself kind of experienced what regards linux problems.
And, if that had had happened once I would have said it has been my fault. I do not think so any more. I consider Btrfs instable and inappropriate for public usage.
I'd go further and would like to ask, *why* this is set as the default root fs when installing. This is totally inunderstandable to me after my experiences.
I never ever experienced any bit of advantage in comparison with ext4. But I experienced nights of work - just to restore a state that had had existed a few days before.
So, please, think it over:
*take Btrfs out as default!*
Use stable and well known systems as the foundation of public systems. Changing things only to change something is leading nowhere.
Besides, if there is a kind soul that can explain what was the reason for making Btrfs the default I would highly appreciate. I cannot see any change besides significantly improved stability when going back to ext4. The latter being the most important thing IMHO.
could we have data or at least a description of the problem? link to forum where you tried to resolve the problem? I find it strange you would expect design descisions to be made on a single persons "opinion" that "something" went "wrong". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello nicholas, have you ever tried to fix a broken Brtfs? I do not think so because your email tells me so. The errors vary, btrfsck is simply not working, you are stuck every other time with a file system that is said to be full though it isnt. And there is no way to fix, try to find some information how to fix broken Btrfs file systems, you'll almost always fail. If a root fs is broken, whom will you ask to fix anything if the tools available are simply disfunctional? Search for "ext4 problem" and search for "btrfs problem". The differences are striking in numbers. There is even a wikipedia article listing tons of problems and may-be-circumvents for btrfs - I do not find anything similar for ext4. Guess why. ext4 problems are usually hardware problems - or someone ran into the overfull - limits. ext4 is simply more forgiving than Btrfs. You did not state why the change to Btrfs was done before ... nobody ever said that so far. My two cents, regards Dieter Jurzitza Am Sonntag, 26. Februar 2017, 08:39:52 schrieb nicholas:
On Sunday, 26 February 2017 08:22:41 CET Dr.-Ing. Dieter Jurzitza wrote:
Dear listmembers, dear openSUSE - maintainers, I maintain about 5 to 6 PC running (openSUSE) linux. My own, my sisters my
could we have data or at least a description of the problem? link to forum where you tried to resolve the problem? I find it strange you would expect design descisions to be made on a single persons "opinion" that "something" went "wrong".
-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 26 February 2017 at 09:02, Dr.-Ing. Dieter Jurzitza <dieter.jurzitza@t-online.de> wrote:
Hello nicholas, have you ever tried to fix a broken Brtfs? I do not think so because your email tells me so.
I have, many times
The errors vary, btrfsck is simply not working, you are stuck every other time with a file system that is said to be full though it isnt. And there is no way to fix, try to find some information how to fix broken Btrfs file systems, you'll almost always fail.
Well that is your problem, if the first thing you do with btrfs is run btrfsck, YOU are liable to break your btrfs filesystem This, and the correct procedure is well documented https://btrfs.wiki.kernel.org/index.php/Btrfsck The above URL is the first hit when I search for "btrfs repair" on duckduckgo, google and big
If a root fs is broken, whom will you ask to fix anything if the tools available are simply disfunctional?
How can we be sure the root fs is broken when you have no provided any of the requested information, and the only information you have provided demonstrates that you clearly didn't look after your root filesystem properly?
Search for "ext4 problem" and search for "btrfs problem". The differences are striking in numbers. There is even a wikipedia article listing tons of problems and may-be-circumvents for btrfs - I do not find anything similar for ext4. Guess why. ext4 problems are usually hardware problems - or someone ran into the overfull - limits. ext4 is simply more forgiving than Btrfs.
Guess what, I've lost more data in the last 5 years to ext4 than I have btrfs.. heck, even my home router is now running btrfs as it's root filesystem and I'm very comfortable with it -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 12:38, Richard Brown wrote:
On 26 February 2017 at 09:02, Dr.-Ing. Dieter Jurzitza <dieter.jurzitza@t-online.de> wrote:
Hello nicholas, have you ever tried to fix a broken Brtfs? I do not think so because your email tells me so.
I have, many times
The errors vary, btrfsck is simply not working, you are stuck every other time with a file system that is said to be full though it isnt. And there is no way to fix, try to find some information how to fix broken Btrfs file systems, you'll almost always fail.
Well that is your problem, if the first thing you do with btrfs is run btrfsck, YOU are liable to break your btrfs filesystem
Then the tool is broken. Don't blame the person, blame the tool! btrfsck should silently and fully repair any problem in the filesystem, period.
If a root fs is broken, whom will you ask to fix anything if the tools available are simply disfunctional?
How can we be sure the root fs is broken when you have no provided any of the requested information, and the only information you have provided demonstrates that you clearly didn't look after your root filesystem properly?
No, you don't have any proof of that, either. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26/02/17 06:58 AM, Carlos E. R. wrote:
Well that is your problem, if the first thing you do with btrfs is run btrfsck, YOU are liable to break your btrfs filesystem
Then the tool is broken. Don't blame the person, blame the tool! btrfsck should silently and fully repair any problem in the filesystem, period.
<rant for Sunday> Well, yes there is that. Every other file system gets repaired by its corresponding FSCK. If the boot sequence sees a problem then it runs the corresponding FSCK. Why should BtrFS be different? I laud the principles behind BtrFS, but sometimes I wonder if the effort wouldn't have been better devoted to a step along the way such as Reiser4. The "One disk to rue them all" taking over all 'spindles' approach drags in a lot. Why couldn't the developers be content with what every other FS has (outside of SUN, that is) with a FS that runs in a partition live everyone else? Can you say "featureitis"? (Well, OK, I bitch and moan about ext4FS as well. Of all the B-Tree file systems the developers there have managed to build one that does NOT have dynamic allocation of i-node space. As I've said before, I HATE pre-provisioning. Why, having the examples of ReiserFS and XFS, other excellent B-tree file systems, to guide them, the developers stuck with a technological approach that dates back to the 1960 and earlier as amplified in the original UNIX V6 file that I first worked with back in the late 1970 I really can't understand. Perhaps this will be rectified in some hypothetical ext5. Oh, wait! That would break backward compatibility! Ah .. yes, here, from my DatabaseOfDotSigQuotes: The proof that IBM didn't invent the car is that it has a steering wheel and an accelerator instead of spurs and ropes, to be compatible with a horse. -- Jac Goudsmit ) </rant for Sunday> -- 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 2017-02-26 15:47, Anton Aylward wrote:
On 26/02/17 06:58 AM, Carlos E. R. wrote:
Well that is your problem, if the first thing you do with btrfs is run btrfsck, YOU are liable to break your btrfs filesystem
Then the tool is broken. Don't blame the person, blame the tool! btrfsck should silently and fully repair any problem in the filesystem, period.
<rant for Sunday> Well, yes there is that. Every other file system gets repaired by its corresponding FSCK. If the boot sequence sees a problem then it runs the corresponding FSCK.
XFS runs one that does nothing. Calling it manually advises what to do.
Why should BtrFS be different?
I laud the principles behind BtrFS, but sometimes I wonder if the effort wouldn't have been better devoted to a step along the way such as Reiser4. The "One disk to rue them all" taking over all 'spindles' approach drags in a lot. Why couldn't the developers be content with what every other FS has (outside of SUN, that is) with a FS that runs in a partition live everyone else? Can you say "featureitis"?
Maybe.
(Well, OK, I bitch and moan about ext4FS as well. Of all the B-Tree file systems the developers there have managed to build one that does NOT have dynamic allocation of i-node space. As I've said before, I HATE pre-provisioning. Why, having the examples of ReiserFS and XFS, other excellent B-tree file systems, to guide them, the developers stuck with a technological approach that dates back to the 1960 and earlier as amplified in the original UNIX V6 file that I first worked with back in the late 1970 I really can't understand. Perhaps this will be rectified in some hypothetical ext5. Oh, wait! That would break backward compatibility!
Oh, I have been caught by destructive failure of all filesystems: fat, ntfs, ext3, xfs, reiserfs, btrfs... only that btrfs has more failures in my experience.
Ah .. yes, here, from my DatabaseOfDotSigQuotes:
The proof that IBM didn't invent the car is that it has a steering wheel and an accelerator instead of spurs and ropes, to be compatible with a horse. -- Jac Goudsmit )
LOL :-)
</rant for Sunday>
:-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 02/26/2017 03:38 AM, Richard Brown wrote:
On 26 February 2017 at 09:02, Dr.-Ing. Dieter Jurzitza <dieter.jurzitza@t-online.de> wrote:
Hello nicholas, have you ever tried to fix a broken Brtfs? I do not think so because your email tells me so. I have, many times
There you have it Dr. Ing. Your theory *confirmed*. After my second dataloss corruption of btrfs I swore it off. Banned from all my systems -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
26.02.2017 14:38, Richard Brown пишет:
On 26 February 2017 at 09:02, Dr.-Ing. Dieter Jurzitza <dieter.jurzitza@t-online.de> wrote:
Hello nicholas, have you ever tried to fix a broken Brtfs? I do not think so because your email tells me so.
I have, many times
The errors vary, btrfsck is simply not working, you are stuck every other time with a file system that is said to be full though it isnt. And there is no way to fix, try to find some information how to fix broken Btrfs file systems, you'll almost always fail.
Well that is your problem, if the first thing you do with btrfs is run btrfsck, YOU are liable to break your btrfs filesystem
Good. So as you appear to be expert in repairng corrupted btrfs - after reboot I get "parent transid failed". Without doing anything in between at all - I just booted and after 10 minutes did "reboot". Of course, even grub does not load now as it itself is located on btrfs and cannot read its modules. Your suggestion? OK I must not use btrfcsk. What I *must* use now? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hmmm. I wonder if it would not hurt for some of us to take another look at: https://en.opensuse.org/openSUSE:Guiding_principles That said, IMHO (if anyone cares), I agree with the sentiment that BTRFS is not ready for the Normal (average and less) home user. Therefore, I really think the Leap installer should offer -- for now -- ext4 as the default file system, with BTRFS as a visible option. But, of course, BTRFS should *not* be dropped, should ship as part of the system as an option. I see it as the file system of the future with great potential. That is for Leap. For Tumbleweed, I think the default *should* be BTRFS. After all, (in my view) Tumbleweed is the bleeding edge and is often used as a testing ground so the wrinkles can be ironed out before things move to Leap. It is my understanding that Tumbleweed users should expect some glitches now and then, and should participate in testing and reporting, if not patching and developing. Of course, ext4 should still be offered as an option in Tumbleweed, for those who must use Tumbleweed because of problems with some new hardware or proprietary drivers. IMHO. For what it is worth. -- -Gerry Makaro aka Fraser_Bell on the forums, IRC, and mail at openSUSE.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 09:02, Dr.-Ing. Dieter Jurzitza wrote:
Hello nicholas, have you ever tried to fix a broken Brtfs? I do not think so because your email tells me so.
The errors vary, btrfsck is simply not working, you are stuck every other time with a file system that is said to be full though it isnt. And there is no way to fix, try to find some information how to fix broken Btrfs file systems, you'll almost always fail.
What partition size were you using? I recommend a minimum size of 100 GiB for "/", with /home separate.
If a root fs is broken, whom will you ask to fix anything if the tools available are simply disfunctional?
Well, ask here. :-) But you are right, the tools should work, automatically, and never make things worse.
Search for "ext4 problem" and search for "btrfs problem". The differences are striking in numbers. There is even a wikipedia article listing tons of problems and may-be-circumvents for btrfs - I do not find anything similar for ext4. Guess why. ext4 problems are usually hardware problems - or someone ran into the overfull - limits. ext4 is simply more forgiving than Btrfs.
Yes, ext4 is the safe choice, I agree.
You did not state why the change to Btrfs was done before ... nobody ever said that so far.
Well, btrfs has new and interesting features. The most important, it has snapshots. I have seen people with no experience install some updates that crash the system. Reboot, choose a previous snapshot, problem solved. In minutes. As compared to finding the offending updates, locate previous versions of the updates, install them if package manager was not broken in the disaster... It has compression. I have not tried it yet, but it is the only r/w Linux filesystem that has it. NTFS has it, since ages. ext4 has the hook, but has never been implemented. Same for XFS. Reiserfs has not it. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Le 26/02/2017 à 13:07, Carlos E. R. a écrit :
What partition size were you using?
I recommend a minimum size of 100 GiB for "/", with /home separate.
same for me. Even with the best setup, btrfs asks for much room if you want to use it's most wanted feature (fe snapshots)
If a root fs is broken, whom will you ask to fix anything if the tools available are simply disfunctional?
Well, ask here. :-)
exactly :-)
But you are right, the tools should work, automatically, and never make things worse.
It's debatable, what tool? I was *always* instructed since 20 years ago *not* to use fsck without knowing exactly what to do, as it's right for dd or some other very lowlevel tool.
Yes, ext4 is the safe choice, I agree.
same for me, specially with 24Gb or even 60Gb ssd I have now as root
Well, btrfs has new and interesting features. The most important, it has snapshots. I have seen people with no experience install some updates that crash the system.
me too Reboot, choose a previous snapshot, problem
solved. In minutes.
not solved at all (no space left on device). Works when the problem come from kernel or similar
It has compression. I have not tried it yet, but it is the only r/w Linux filesystem that has it. NTFS has it, since ages.
I challenge the need with so large mass storage - most large files I know are photo or video and they don't compress well (already natively compressed) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 14:45, jdd wrote:
Le 26/02/2017 à 13:07, Carlos E. R. a écrit :
If a root fs is broken, whom will you ask to fix anything if the tools available are simply disfunctional?
Well, ask here. :-)
exactly :-)
The snag is, you need a working computer and wait several days with a broken computer.
But you are right, the tools should work, automatically, and never make things worse.
It's debatable, what tool? I was *always* instructed since 20 years ago *not* to use fsck without knowing exactly what to do, as it's right for dd or some other very lowlevel tool.
One tool. The first thing I do with any filesystem that I suspect is broken, is fsck it. Always. On some, like XFS, that program does nothing and tells me what other program to use, and that other tool works on most cases out of the box. It it doesn't, it recommends what to do next: typically run it again with some option. If all that fails, then email the XFS support mail list. In most of my cases, I had found a new bug, or it was an already known bug which required a new version of the repair tools, already built for openSUSE in the expected repo.
Reboot, choose a previous snapshot, problem
solved. In minutes.
not solved at all (no space left on device). Works when the problem come from kernel or similar
Well, you must never get close to no space on btrfs.
It has compression. I have not tried it yet, but it is the only r/w Linux filesystem that has it. NTFS has it, since ages.
I challenge the need with so large mass storage - most large files I know are photo or video and they don't compress well (already natively compressed)
Well, it irks me not to use compression on things that can use it. For instance, email and news. Big and/or many text files. Backups are often compressed: tgz, zip, rar... I could instead use rsync on a compressed destination disk. Or dd, many empty sectors. But I can't trust it! :-( -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Le 26/02/2017 à 15:52, Carlos E. R. a écrit :
Backups are often compressed: tgz, zip, rar...
main goal is grouping (archive), not compress apart fort ext files, but this was usefull and is no more I remember then when I was still on windows (windows Nt time), compression was said to be faster because of less disk access :-)) jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 15:59, jdd wrote:
Le 26/02/2017 à 15:52, Carlos E. R. a écrit :
Backups are often compressed: tgz, zip, rar...
main goal is grouping (archive), not compress
I think it is both. There is a sweet setting that speeds up the process, less writing. Too much compression and it is slower.
apart fort ext files, but this was usefull and is no more
I remember then when I was still on windows (windows Nt time), compression was said to be faster because of less disk access :-))
There is that, too. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Carlos E. R. wrote:
Well, it irks me not to use compression on things that can use it. For instance, email and news. Big and/or many text files. Backups are often compressed: tgz, zip, rar... I could instead use rsync on a compressed destination disk. Or dd, many empty sectors.
&&
I think it is both. There is a sweet setting that speeds up the process, less writing. Too much compression and it is slower.
--- If you compress email, it makes grep'ing through it much slower... Really depends on your disks and backup media. gzip -1 ... about best I see is ~50MB/s on compress on a 2.6 GHz processor (from a file in memory to /dev/null). So that's about 20.5 seconds for 1G, or near 6 hours/TB -- and that's not counting "read time" from the source or writing to the final media -- that's just compress time. So one 4TB disk would take a day? Just to compress? Sounds masochistic... Maybe if I backed up to a cloud... but who would trust that ( for reliability or privacy)... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-27 19:11, L A Walsh wrote:
Carlos E. R. wrote:
Well, it irks me not to use compression on things that can use it. For instance, email and news. Big and/or many text files. Backups are often compressed: tgz, zip, rar... I could instead use rsync on a compressed destination disk. Or dd, many empty sectors.
&&
I think it is both. There is a sweet setting that speeds up the process, less writing. Too much compression and it is slower.
--- If you compress email, it makes grep'ing through it much slower...
Then it is compressed too much, or it is not coded right: one core decompressing, one core analysing.
Really depends on your disks and backup media.
Yes, it does. For instance, with this laptop I have to backup via usb cable, which is slow. Compressing does make a difference.
gzip -1 ... about best I see is ~50MB/s on compress on a 2.6 GHz processor (from a file in memory to /dev/null).
So that's about 20.5 seconds for 1G, or near 6 hours/TB -- and that's not counting "read time" from the source or writing to the final media -- that's just compress time.
Ah, good test. time zip -1 /run/user/1000/ziptest Mail/* ... real 0m23.382s user 0m16.891s sys 0m0.775s That's 371,981,765 MB in 23", ie 15 MiB/s. Too slow. time rar a -m1 /run/user/1000/ziptest Mail/ ... real 0m24.240s user 0m34.348s sys 0m2.178s Well, at least with these compressing methods it wouldn't be worth it, in speed terms. What other compressors can I test? Although the real test would be with a btrfs partition with compression enabled, see how it fares. Perhaps also zfs. But I can not do that testing in this machine. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Carlos E. R. wrote:
--- If you compress email, it makes grep'ing through it much slower...
Then it is compressed too much, or it is not coded right: one core decompressing, one core analysing.
--- Like I said, gzip -0 is "too much" -- any compression will be slower. 'grep' from a file in memory @2.7GB -- takes 1.24s. That gives 2.12TB/s. So far none of the compress utils exceed ~100MB/s
Really depends on your disks and backup media.
Yes, it does. For instance, with this laptop I have to backup via usb cable, which is slow. Compressing does make a difference.
--- Have you run 'dd' tests to see what max speeds are? remember to use direct i/o for writes, though best to test with and without DIO, as a USB disk might be slow enough to get some benefit from the linux disk cache. But to give you an idea of how little overhead it takes to slow things down -- writing a 8GB to a file through the disk cache (conv=fdatasync): 473.5MB/s, writing a file direct (oflag=direct): 898MB/s. (All figures use 2**10 based prefixes, not 10**3). To get closer, try to make sure your destination file doesn't have holes in it. FWIW, I used:
time bash -c 'dd if=/dev/zero of=1TB bs=64M count=128 oflag=direct
xz, lzma, 7z (all similar), bzip2 ncompress(compress), lzop (fastest I have, but only about 2x gz), and likely the slowest (but maybe best compression): rzip. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-28 06:52, L A Walsh wrote:
Carlos E. R. wrote:
Like I said, gzip -0 is "too much" -- any compression will be slower. 'grep' from a file in memory @2.7GB -- takes 1.24s. That gives 2.12TB/s. So far none of the compress utils exceed ~100MB/s
There is something wrong somewhere. My tests are old, anyway.
Really depends on your disks and backup media.
Yes, it does. For instance, with this laptop I have to backup via usb cable, which is slow. Compressing does make a difference.
--- Have you run 'dd' tests to see what max speeds are? remember to use direct i/o for writes, though best to test
USB 2, remember. That makes about 20..30 MB/s, IIRC. can be tested with "hdparm -tT", but I don't have the disk connected now. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Carlos E. R. wrote:
On 2017-02-28 06:52, L A Walsh wrote:
Carlos E. R. wrote:
Like I said, gzip -0 is "too much" -- any compression will be slower. 'grep' from a file in memory @2.7GB -- takes 1.24s. That gives 2.12TB/s. So far none of the compress utils exceed ~100MB/s
^^^^^ Make that 2.12GB/s.... Oi!
Well, that's out of memory... multiple files from disk is going to be <1GB/s -- still an order magnitude faster than one can uncompress...
There is something wrong somewhere. My tests are old, anyway.
Indeed. :^? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday, 26 February 2017 15:52:42 CET Carlos E. R. wrote:
The first thing I do with any filesystem that I suspect is broken, is fsck it. Always.
you impliment a single course of action/modification before diagnosis and irrespective of the system recomendations? such working practices would not go down well in any safety critcal industry (in medicine it would be called malpractice). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 26/02/17 15:22, nicholas wrote:
On Sunday, 26 February 2017 15:52:42 CET Carlos E. R. wrote:
The first thing I do with any filesystem that I suspect is broken, is fsck it. Always.
you impliment a single course of action/modification before diagnosis and irrespective of the system recomendations? such working practices would not go down well in any safety critcal industry (in medicine it would be called malpractice).
I think you'll find it is not unusual, even in medicine :-( which - as normally practised - is most definitely NOT a Science. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday, 26 February 2017 16:27:04 CET Wols Lists wrote:
On 26/02/17 15:22, nicholas wrote:
On Sunday, 26 February 2017 15:52:42 CET Carlos E. R. wrote:
The first thing I do with any filesystem that I suspect is broken, is fsck it. Always.
you impliment a single course of action/modification before diagnosis and irrespective of the system recomendations? such working practices would not go down well in any safety critcal industry (in medicine it would be called malpractice).
I think you'll find it is not unusual, even in medicine :-( which - as normally practised - is most definitely NOT a Science.
Cheers, Wol
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 16:22, nicholas wrote:
On Sunday, 26 February 2017 15:52:42 CET Carlos E. R. wrote:
The first thing I do with any filesystem that I suspect is broken, is fsck it. Always.
you impliment a single course of action/modification before diagnosis and irrespective of the system recomendations? such working practices would not go down well in any safety critcal industry (in medicine it would be called malpractice).
I let fsck do the diagnostic. Why should I need to know how to diagnose it? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
nicholas wrote:
On Sunday, 26 February 2017 15:52:42 CET Carlos E. R. wrote:
The first thing I do with any filesystem that I suspect is broken, is fsck it. Always.
you impliment a single course of action/modification before diagnosis and irrespective of the system recomendations? such working practices would not go down well in any safety critcal industry (in medicine it would be called malpractice).
---- fsck *IS* supposed to be a first line diagnostic for file systems (unless the file system is designed to work without such -- like some journaling fs's. It's likely it won't be too many more years before 1st course of action in diagnosing a patient will be to run a computer workup of their symptoms. NOT doing so as a 1st line of action would be considered malpractice. Right now, medicine just isn't advanced enough to have a computer do it. Using a 'fsck' for a given file system would certainly be one of my first choices in analyzing it. If such a tool harmed the file system, then that's a severe bug in the file-system + fsck. Is btrfs being used on suse's supported server offerings? That's where you need to look to see if it is being used for "prime time". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
27.02.2017 21:27, L A Walsh пишет:
Is btrfs being used on suse's supported server offerings?
Yes, it is default filesystem for root on SLES12 (including snapper). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 27/02/17 18:27, L A Walsh wrote:
It's likely it won't be too many more years before 1st course of action in diagnosing a patient will be to run a computer workup of their symptoms. NOT doing so as a 1st line of action would be considered malpractice.
Right now, medicine just isn't advanced enough to have a computer do it.
Then why do I remember - FROM THE 1980S - computer programs that were better than doctors at diagnosing illnesses? The critical factor in being able to diagnose, is having the experience. And the majority of GPs don't have the experience. (Not their fault, it comes with age.) A simple program, written to run on an S100 system with 64K of ram, could probably do better than most doctors today. All it needs is a simple diagnostic database. I can't remember the AI language it was written in. You are falling into the trap of assuming we are much better than our predecessors - I studied some medical history, and it's striking how good the doctors of centuries past were at diagnosing illnesses - they were most definitely the equal of todays. Where we are much better than they are is that we have many more cures available to us, but even then, the biggest advance in health care for centuries has been clean water! Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Wols Lists wrote:
I can't remember the AI language it was written in.
Prologue, I believe. But it didn't run from raw data -- it ran from a Q&A of symptoms, like 20 questions. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 26/02/17 09:52 AM, Carlos E. R. wrote:
The first thing I do with any filesystem that I suspect is broken, is fsck it. Always.
I was taught that too, so far back in antiquity I suspect that the machines I was using then have long been recycled for scrap.
On some, like XFS, that program does nothing and tells me what other program to use,
BTDT. It told me to get an updated version of FSCK :-) Now *THAT* is the kind of smarts that I like!
and that other tool works on most cases out of the box.
And it did! Given a choice between XFS and BtrFS I'd take XFS.
It it doesn't, it recommends what to do next: typically run it again with some option.
-- 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 2017-02-26 16:37, Anton Aylward wrote:
On 26/02/17 09:52 AM, Carlos E. R. wrote:
The first thing I do with any filesystem that I suspect is broken, is fsck it. Always.
I was taught that too, so far back in antiquity I suspect that the machines I was using then have long been recycled for scrap.
Yes, it is ancient usage. Even on msdos.
On some, like XFS, that program does nothing and tells me what other program to use,
BTDT. It told me to get an updated version of FSCK :-)
Now *THAT* is the kind of smarts that I like!
It is a simple script. Get an updated version is not there: cer@minas-tirith:~> cat /usr/sbin/fsck.xfs #!/bin/sh -f # # Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved. # AUTO=false while getopts ":aApy" c do case $c in a|A|p|y) AUTO=true;; esac done eval DEV=\${$#} if [ ! -e $DEV ]; then echo "$0: $DEV does not exist" exit 8 fi if $AUTO; then echo "$0: XFS file system." else echo "If you wish to check the consistency of an XFS filesystem or" echo "repair a damaged filesystem, see xfs_repair(8)." fi exit 0 cer@minas-tirith:~> -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26/02/17 12:07, Carlos E. R. wrote:
On 2017-02-26 09:02, Dr.-Ing. Dieter Jurzitza wrote:
Hello nicholas, have you ever tried to fix a broken Brtfs? I do not think so because your email tells me so.
The errors vary, btrfsck is simply not working, you are stuck every other time with a file system that is said to be full though it isnt. And there is no way to fix, try to find some information how to fix broken Btrfs file systems, you'll almost always fail. What partition size were you using?
I recommend a minimum size of 100 GiB for "/", with /home separate.
I let SuSE do its own thing, but what I picked up very early in investigating btrfs was a) the concept of "how much free space is there" doesn't make sense in a btrfs scenario. b) you do NOT want a "disk full" scenario - if you combine that with snapshots (which SuSE does as a matter of course for the root partition) you are just begging for a disaster to happen ...
If a root fs is broken, whom will you ask to fix anything if the tools available are simply disfunctional? Well, ask here. :-)
But you are right, the tools should work, automatically, and never make things worse.
c) btrfsck just shouldn't exist - it's been a disaster pretty much from day 1. Probably written for those people who demanded a fsck tool, by someone who didn't understand that btrfs was a work in progress and you can't run a bit-rotted fsck on an updated filesystem :-( aiui, btrfs as implemented in SuSE is a cut-down version, with most of the experimental and unstable features removed. The only known real problem is that one with snapshots and a disk full. Which a sys-admin should pick up and deal with before it becomes serious. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
26.02.2017 16:46, Anthony Youngman пишет:
aiui, btrfs as implemented in SuSE is a cut-down version, with most of the experimental and unstable features removed.
I am not aware of any feature removal. Can you provide pointers? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 26/02/17 13:49, Andrei Borzenkov wrote:
26.02.2017 16:46, Anthony Youngman пишет:
aiui, btrfs as implemented in SuSE is a cut-down version, with most of the experimental and unstable features removed.
I am not aware of any feature removal. Can you provide pointers?
Bear in mind, I'm active on raid so I'm not that interested in btrfs unless it impacts on raid, but when digging I got the strong impression that ... Raid 0 and 1 work fine on btrfs. Anything higher is a disaster area. And that SuSE disable by default any of those features that cause problems. So I *guess* that things like raid 5 and 6 aren't there. (I guess, as a raid guy, I'd probably recommend a "disk - raid5 - btrfs" stack for anybody who wanted that sort of functionality.) (And my main "doing the work" system runs gentoo over ext4 over raid1 :-) Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 14:49, Andrei Borzenkov wrote:
26.02.2017 16:46, Anthony Youngman пишет:
aiui, btrfs as implemented in SuSE is a cut-down version, with most of the experimental and unstable features removed.
I am not aware of any feature removal. Can you provide pointers?
I don't remember the details, but several. Was discussed on factory list previous to release of 13.1 or later. Perhaps on Leap. On each release they considered what to disable, I think following the opinion of SLE devs. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Le 26/02/2017 à 14:46, Anthony Youngman a écrit :
The only known real problem is that one with snapshots and a disk full. Which a sys-admin should pick up and deal with before it becomes serious.
probably. It was the only one that it me (several times) - and I wonder when it will addressed from the install it's one of my unsolved problem: when I do a new system install (fe 42.2), do I test the new file system expecting it to be fixed or do I keep the old one I know? jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday, 26 February 2017 14:52:41 CET jdd wrote:
Le 26/02/2017 à 14:46, Anthony Youngman a écrit :
The only known real problem is that one with snapshots and a disk full. Which a sys-admin should pick up and deal with before it becomes serious.
probably. It was the only one that it me (several times) - and I wonder when it will addressed from the install
it's one of my unsolved problem: when I do a new system install (fe 42.2), do I test the new file system expecting it to be fixed or do I keep the old one I know?
jdd
you want a file system which will stop you filling it?? snapshots take as much or as little as you (or defaults) dictate. FYI: there are now also quotas which can help prevent disk full alias space='sudo btrfs filesystem usage -h /' (keeps an eye on things) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 26/02/2017 à 15:06, nicholas a écrit :
On Sunday, 26 February 2017 14:52:41 CET jdd wrote:
Le 26/02/2017 à 14:46, Anthony Youngman a écrit :
The only known real problem is that one with snapshots and a disk full. Which a sys-admin should pick up and deal with before it becomes serious.
probably. It was the only one that it me (several times) - and I wonder when it will addressed from the install
it's one of my unsolved problem: when I do a new system install (fe 42.2), do I test the new file system expecting it to be fixed or do I keep the old one I know?
jdd
you want a file system which will stop you filling it?? snapshots take as much or as little as you (or defaults) dictate.
FYI: there are now also quotas which can help prevent disk full alias space='sudo btrfs filesystem usage -h /' (keeps an eye on things)
no. I want an install system that, when allowed to take all the disk, make a choice that allows system surviving an update after two month out of network. jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 15:06, nicholas wrote:
On Sunday, 26 February 2017 14:52:41 CET jdd wrote:
probably. It was the only one that it me (several times) - and I wonder when it will addressed from the install
it's one of my unsolved problem: when I do a new system install (fe 42.2), do I test the new file system expecting it to be fixed or do I keep the old one I know?
jdd
you want a file system which will stop you filling it?? snapshots take as much or as little as you (or defaults) dictate.
Not really. People use the defaults. Then they do updates routinely. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
nicholas wrote:
you want a file system which will stop you filling it?? snapshots take as much or as little as you (or defaults) dictate.
The minimum functionality I'd want there would be to set the size 'snapshots' could use. If it hits that limit it must recycle older snapshots or stop taking snapshots. T Does BTRFS allow that? Does it get installed that way by default (say to leave 5-15% free based on disk size?)?
FYI: there are now also quotas which can help prevent disk full alias space='sudo btrfs filesystem usage -h /' (keeps an eye on things)
who runs that? No person, I hope. i.e. keeping an eye on things has to be done automatically. Balancing and keeping free space is something that should be done automatically and by default. The maximum a user can config for snapshots in Windows is 15%, with less being the usually case on smaller disks. I have mine set for 3% (~25G) even though system restore is broken (I can still access previous versions of files which is occasionally useful). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 14:52, jdd wrote:
Le 26/02/2017 à 14:46, Anthony Youngman a écrit :
The only known real problem is that one with snapshots and a disk full. Which a sys-admin should pick up and deal with before it becomes serious.
If you need a sysadmin to care, then that filesystem is not ready for the main public that use openSUSE.
probably. It was the only one that it me (several times) - and I wonder when it will addressed from the install
it -> hit ;-) Yes.
it's one of my unsolved problem: when I do a new system install (fe 42.2), do I test the new file system expecting it to be fixed or do I keep the old one I know?
For me, it is clear: ext4. Probably for years to come. I may use btrfs on non crucial partitions. I want to, but I'm scared. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26/02/17 09:59 AM, Carlos E. R. wrote:
If you need a sysadmin to care, then that filesystem is not ready for the main public that use openSUSE.
There's a generic here. What is "professional" grade and what it "Joe Public" grade are two different things. We can see that in all manner of things from Planes, Trains and Automobiles to cameras. Cameras? Well consider the number of settings, the number of control knobs on a high end Canon, Nikon or Sony and consider what it takes to and how many control you have on the basic out-of-the-box consumer level snapshot camera such as you get on a cell phone. They are marketed quite differently. To a professional its the quality of the lens, the quality and light gathering power of the sensor. A true professional wants a digital camera that has RAW settings because more than half his work is in the 'digital darkroom', just as his ancestors in the profession relied on the optical/chemical darkroom. Snapshot cameras are sold on the basis of "more pixels" and the number of "artistic" functions available on the 'phone. Planes? Consider the complexity of the cabin and controls of a commercial airliner (and the training the pilots need) to the number of instruments in a "small" plane like Piper Cub. And so it goes. Microsoft used to make point between a "Home" system and a "Professional" system. Do they still? How much difference in syadmin knowledge between the two? -- 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 2017-02-26 18:25, Anton Aylward wrote:
On 26/02/17 09:59 AM, Carlos E. R. wrote:
If you need a sysadmin to care, then that filesystem is not ready for the main public that use openSUSE.
There's a generic here. What is "professional" grade and what it "Joe Public" grade are two different things.
We can see that in all manner of things from Planes, Trains and Automobiles to cameras.
Microsoft used to make point between a "Home" system and a "Professional" system. Do they still? How much difference in syadmin knowledge between the two?
Yes, they still do; but what is different is the included applications and feature. Maybe the licenses. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Hello! 26.02.2017 15:46, Anthony Youngman пишет:
The only known real problem is that one with snapshots and a disk full. Which a sys-admin should pick up and deal with before it becomes serious.
Oh, yes. I was "lucky" to get this on virtual machine, but this was enough for me to keep on using ext4 on / in future. I'm scared of using btrfs. :( -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 14:57, Mikhail Kasimov wrote:
Hello!
26.02.2017 15:46, Anthony Youngman пишет:
The only known real problem is that one with snapshots and a disk full. Which a sys-admin should pick up and deal with before it becomes serious.
Oh, yes. I was "lucky" to get this on virtual machine, but this was enough for me to keep on using ext4 on / in future. I'm scared of using btrfs. :(
Afraid? I use BTRFS since 12.2, for my private OBS-mirror. (daily rsync from GWDG) Except for some power glitches I never had any problems with this dell-server. Just because I don't want to "fix" something that ain't broken, it is still doing btrfs on 12.2 Fast, reliable. Just as SuSE systems should be. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 26-02-17 13:07, Carlos E. R. wrote:
You did not state why the change to Btrfs was done before ... nobody ever said that so far. Well, btrfs has new and interesting features. The most important, it has snapshots. I have seen people with no experience install some updates
On 2017-02-26 09:02, Dr.-Ing. Dieter Jurzitza wrote: ... that crash the system. Reboot, choose a previous snapshot, problem solved. In minutes.
As compared to finding the offending updates, locate previous versions of the updates, install them if package manager was not broken in the disaster...
It has compression. I have not tried it yet, but it is the only r/w Linux filesystem that has it. NTFS has it, since ages. ext4 has the hook, but has never been implemented. Same for XFS. Reiserfs has not it.
ZFS has all of these and is more mature than BTRFS... gr arno -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 15:39, ArnoB wrote:
On 26-02-17 13:07, Carlos E. R. wrote:
It has compression. I have not tried it yet, but it is the only r/w Linux filesystem that has it. NTFS has it, since ages. ext4 has the hook, but has never been implemented. Same for XFS. Reiserfs has not it.
ZFS has all of these and is more mature than BTRFS...
cer@minas-tirith:~> cat /proc/filesystems | grep -i zfs cer@minas-tirith:~> -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26-02-17 16:04, Carlos E. R. wrote:
On 2017-02-26 15:39, ArnoB wrote:
On 26-02-17 13:07, Carlos E. R. wrote:
It has compression. I have not tried it yet, but it is the only r/w Linux filesystem that has it. NTFS has it, since ages. ext4 has the hook, but has never been implemented. Same for XFS. Reiserfs has not it.
ZFS has all of these and is more mature than BTRFS...
cer@minas-tirith:~> cat /proc/filesystems | grep -i zfs cer@minas-tirith:~>
that's funny Carl, I didn't know a filesystem can only be called 'a linux filesystem' if it's installed on your computer... Mine returns something else: % cat /proc/filesystems | grep -i zfs nodev zfs % Also, is XFS not a linux filesystem then? % cat /proc/filesystems | grep -i xfs % ;) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 16:33, ArnoB wrote:
On 26-02-17 16:04, Carlos E. R. wrote:
On 2017-02-26 15:39, ArnoB wrote:
On 26-02-17 13:07, Carlos E. R. wrote:
ZFS has all of these and is more mature than BTRFS...
cer@minas-tirith:~> cat /proc/filesystems | grep -i zfs cer@minas-tirith:~>
that's funny Carl, I didn't know a filesystem can only be called 'a linux filesystem' if it's installed on your computer...
Well, it is proprietary, not supported by default. IIRC, YaST doesn't.
Mine returns something else: % cat /proc/filesystems | grep -i zfs nodev zfs %
Also, is XFS not a linux filesystem then? % cat /proc/filesystems | grep -i xfs %
;)
I get xfs. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26-02-17 18:35, Carlos E. R. wrote:
On 2017-02-26 16:33, ArnoB wrote:
On 26-02-17 16:04, Carlos E. R. wrote:
On 2017-02-26 15:39, ArnoB wrote:
On 26-02-17 13:07, Carlos E. R. wrote:
ZFS has all of these and is more mature than BTRFS... cer@minas-tirith:~> cat /proc/filesystems | grep -i zfs cer@minas-tirith:~>
that's funny Carl, I didn't know a filesystem can only be called 'a linux filesystem' if it's installed on your computer... Well, it is proprietary, not supported by default. IIRC, YaST doesn't. i wouldn't call something with a CDDL license is proprietary... Thing is, BTRFS is modeled after ZFS.
Sun did the initial development of ZFS. Apple implemented it in OSX immediately after it was open sourced, yet never released it officially because of Sun's acquisition by Oracle. Apple did release their code though. FreeBSD also implemented ZFS and it's its second main FS, together with UFS. Since it was discovered that BSD licensed software can be used on GPL ZFS is available for any linux distro: http://www.open-zfs.org/wiki/Main_Page it also runs on a few of the world's top 10 super computers: http://wiki.lustre.org/Category:ZFS http://computation.llnl.gov/projects/zfs-lustre On a smaller level, it nice to be able to swap a drive between OSX, Linux and BSD without any problems. Have a look at this if you;re interested: https://en.wikipedia.org/wiki/ZFS it's a pity Linux has its own license in the way again...
Mine returns something else: % cat /proc/filesystems | grep -i zfs nodev zfs %
Also, is XFS not a linux filesystem then? % cat /proc/filesystems | grep -i xfs %
;) I get xfs.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 19:21, ArnoB wrote: ...
Have a look at this if you;re interested: https://en.wikipedia.org/wiki/ZFS
it's a pity Linux has its own license in the way again...
Well, it doesn't seem trivial to include it in my system. Apparently it is in the "filesystems" repo. What if it breaks? How about bugzillas? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26-02-17 19:46, Carlos E. R. wrote:
On 2017-02-26 19:21, ArnoB wrote:
...
Have a look at this if you;re interested: https://en.wikipedia.org/wiki/ZFS
it's a pity Linux has its own license in the way again... Well, it doesn't seem trivial to include it in my system. Apparently it is in the "filesystems" repo.
What if it breaks? How about bugzillas?
There are a couple of dedicated lists but mainly: http://open-zfs.org/wiki/Main_Page ZFS for OSX is a fork from the Linux driver so they're almost identical and issues can be sent to the linux list Freebsd has a dedicated list as well. zfs for freebsd is ahead of the others. They also advertise the openzfs site for development. I haven't had a single issue since ZFS went out of beta in FreeBSD 7. I don't run high traffic servers though. A few OSX production workstations, a few BSD servers for my company and on an OpenSUSE laptop. All my personal files have been on ZFS for almost 10 years now. Life becomes boring when there's nothing to worry about ;) gr arno -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 26-02-17 16:04, Carlos E. R. wrote:
On 2017-02-26 15:39, ArnoB wrote:
On 26-02-17 13:07, Carlos E. R. wrote:
It has compression. I have not tried it yet, but it is the only r/w Linux filesystem that has it. NTFS has it, since ages. ext4 has the hook, but has never been implemented. Same for XFS. Reiserfs has not it.
ZFS has all of these and is more mature than BTRFS...
cer@minas-tirith:~> cat /proc/filesystems | grep -i zfs cer@minas-tirith:~>
ha! and even funnier: % cat /proc/filesystems | grep -i ext % -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* ArnoB <opensuse@rgbaz.eu> [02-26-17 10:38]:
On 26-02-17 16:04, Carlos E. R. wrote:
On 2017-02-26 15:39, ArnoB wrote:
On 26-02-17 13:07, Carlos E. R. wrote:
It has compression. I have not tried it yet, but it is the only r/w Linux filesystem that has it. NTFS has it, since ages. ext4 has the hook, but has never been implemented. Same for XFS. Reiserfs has not it.
ZFS has all of these and is more mature than BTRFS...
cer@minas-tirith:~> cat /proc/filesystems | grep -i zfs cer@minas-tirith:~>
ha! and even funnier: % cat /proc/filesystems | grep -i ext %
even funnier, using two commands where one suffices: grep -i ext /proc/filesystems ext3 ext2 ext4 -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 Photos: http://wahoo.no-ip.org/piwigo @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello Carlos, I am quite astonished what a reaction has been triggered by my writing. To comment what Carlos has been saying: I usually have a partition setup with /boot, / and /home as separate partitions. Because / does not change significantly there is IMHO no real need for it to be that large, 50 GByte - 100 GByte should be more than sufficient. If that is inappropriate with btrfs - well, I'd say again, then this fs is not appropriate for the things a normal user would do. In my mind 50 GByte - 100 GByte are more than enough for a root file system, where usually nothing happens but a little writing to and from /tmp and /var/tmp. "The music plays" in /home, what I'd make as big as possible. And, +1 for the comments of Carlos with regard to btrfsck - if using it breaks the file system, then it should nor be distributed neither installed. A regular approach is to check a filesystem with XXXfsck, and it is the very responsibility of that tool to not destroy anything and to guide you through problems if problems are found. At the end of the das I would like to rise the question again: "btrfs has new and interesting features". Well, for whom? Am I offered a car with 5 rather than 4 wheels now? Does this help me getting better from location A to location B? I would expect that distribution maintainers are very very careful when it comes to changing the basic basic infrastructure of a system - and, in this case I see no good reason for this to be done. Something new is not neccessarily good, newness is no positive attribute as such, and when the only _siginificant_*) difference can be reduced to "because it is new", then there is no sense in the switch - IMHO, as always. And, something old in turn is not neccessarily bad simply because it is old. The most reliable elements in a linux systems are the tools like "dd", "tar", "ls" and so on and so forth. Take care Dieter Jurzitza *) if you have a speed limit of 60 MPh, what is the benefit from driving a Porsche compared to a Golf? If the answer can be reduced to "the knowledge that it is a Porsche" then there is no rationality in using the latter. -- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 26/02/17 12:04 PM, Dr.-Ing. Dieter Jurzitza wrote:
In my mind 50 GByte - 100 GByte are more than enough for a root file system, where usually nothing happens but a little writing to and from /tmp and /var/tmp.
There are excellent reasons to have /tmp and /var each on separate file system/partitions, each with a different kind of optimization to suit the traffic. Oh, and /srv and perhaps /opt and /local as well. The latter will simplify things things when it comes to doing upgrades. Trust me on that! It really does make life simpler on upgrades! Given my druthers, I'd follow on the idea of "No Traffic" on the RootFS by making it read-only. There's a bit of security in that. (I suppose if you're obsessive you would follow that with /usr/bin/, /usr/sbin/, /usr/lin{64/,/} being on a RO FS (perhaps with symlinks from /usr) as well.) Oh, yes, it amazing what you can do with a snipping a wire and replacing it with a switch! All these multi-terabyte drives have a lot of downsides! Having separate 50M, 100M drives also means a lot of parallelism and the CompSci books are are always pointing you that with parallelism comes performance ... Yeh, right! .... and then you wake up ... -- 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 2017-02-26 18:41, Anton Aylward wrote:
On 26/02/17 12:04 PM, Dr.-Ing. Dieter Jurzitza wrote:
In my mind 50 GByte - 100 GByte are more than enough for a root file system, where usually nothing happens but a little writing to and from /tmp and /var/tmp.
There are excellent reasons to have /tmp and /var each on separate file system/partitions,
Not when you use btrfs. You need them on the same partition for snapshots to work. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26/02/17 01:11 PM, Carlos E. R. wrote:
On 2017-02-26 18:41, Anton Aylward wrote:
On 26/02/17 12:04 PM, Dr.-Ing. Dieter Jurzitza wrote:
In my mind 50 GByte - 100 GByte are more than enough for a root file system, where usually nothing happens but a little writing to and from /tmp and /var/tmp.
There are excellent reasons to have /tmp and /var each on separate file system/partitions,
Not when you use btrfs. You need them on the same partition for snapshots to work.
No you don't Even using BtrFS you can have the snapshot mechanism with/on different file systems. If you look at the config file (or read the man page in detail) you'll see there is a file under /etc/snapper/configs/ for each volume. There's also, in a parallel directory, a template, to show you how it can be done. See also: SNAPPER-CONFIGS(5) But, as I say, if you use LVM you can use snapper on any file system, ext[234], xfs, reiserfs, by means of 'thin volumes. See https://lizards.opensuse.org/2012/07/25/snapper-lvm/ -- 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 2017-02-26 20:19, Anton Aylward wrote:
On 26/02/17 01:11 PM, Carlos E. R. wrote:
On 2017-02-26 18:41, Anton Aylward wrote:
On 26/02/17 12:04 PM, Dr.-Ing. Dieter Jurzitza wrote:
In my mind 50 GByte - 100 GByte are more than enough for a root file system, where usually nothing happens but a little writing to and from /tmp and /var/tmp.
There are excellent reasons to have /tmp and /var each on separate file system/partitions,
Not when you use btrfs. You need them on the same partition for snapshots to work.
No you don't
Yes, you absolutely do. If you want the rollback mechanishm on boot to work, you do. And it is not me who said that. You can have snapshots, yes, but not the rollback feature on boot. The ability to boot an older snapshot, then make it the current one. "/" must be a single partition. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26/02/17 02:22 PM, Carlos E. R. wrote:
You can have snapshots, yes, but not the rollback feature on boot. The ability to boot an older snapshot, then make it the current one. "/" must be a single partition.
I think that's an ambiguous wording. What do you mean by "/" in that? If you are saying that the root FS needs to have /boot then yes I agree. After all the binaries in /boot correspond to the, for example, kernel modules in /lib/modules. But I'll insist that purely data parts of the tree that aren't involved in the boot sequence, such as /home, and the stuff used by Apache under /srv, and the stuff that isn't used until the system is up and running and applications are needed such as /local and quite probably /usr/share, and many others that aren't needed until someone logs in are exempt. I'm not being absolutist in "data is data and code is code and never the twain shall meet". After all,, there's a lot of 'data' needed to get the system up, things in /etc, the 'data' such as systemd's units. One reason to have /usr as part of the boot & RootFS -- but not things in /usr/share like the man pages, obviously! BTDT. Please don't tell me I can't do what I've been doing successfully for a while. -- 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
Le 26/02/2017 à 22:36, Anton Aylward a écrit :
BTDT. Please don't tell me I can't do what I've been doing successfully for a while.
there may still be the risk of a failure that happen only rarely. one person experiment is no proof, that's why reading such thread is instructive :-) that's also why default should be wise, because anybody should be able to trust default as the most safe way to work jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 22:36, Anton Aylward wrote:
On 26/02/17 02:22 PM, Carlos E. R. wrote:
You can have snapshots, yes, but not the rollback feature on boot. The ability to boot an older snapshot, then make it the current one. "/" must be a single partition.
I think that's an ambiguous wording. What do you mean by "/" in that?
It needs to control /boot, /var, /usr, /lib, /bin, /sbin... Dunno /tmp. Some parts are not included, like /var/log, databases, and such. But the rpm database is reverted, I think. I don't know if there is a list of the volumes that btrfs snapshots needs to control. All data directories can be separated, like /home, /srv...
If you are saying that the root FS needs to have /boot then yes I agree. After all the binaries in /boot correspond to the, for example, kernel modules in /lib/modules.
Exactly.
But I'll insist that purely data parts of the tree that aren't involved in the boot sequence, such as /home, and the stuff used by Apache under /srv, and the stuff that isn't used until the system is up and running and applications are needed such as /local and quite probably /usr/share, and many others that aren't needed until someone logs in are exempt.
All /usr must be controlled by the snapshot-rollback mechanism. Data yes, can be outside. Better, should be outside. the /local directory, i don't know, I haven't thought it out. /etc is included.
I'm not being absolutist in "data is data and code is code and never the twain shall meet". After all,, there's a lot of 'data' needed to get the system up, things in /etc, the 'data' such as systemd's units. One reason to have /usr as part of the boot & RootFS -- but not things in /usr/share like the man pages, obviously!
All that comes in rpms needs be included, because it can be reverted.
BTDT. Please don't tell me I can't do what I've been doing successfully for a while.
-- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26/02/17 05:42 PM, Carlos E. R. wrote:
All /usr must be controlled by the snapshot-rollback mechanism.
I disagree. There is no need for, for example, /usr/share/man and a lot more. it looks to me as if all of /usr/share can be excluded. That's "by design". Back when, Bell's USG came up with /usr/share so that the server could have t and make it accessible as NFS to all the other machines. You really think a couple of dozen of the GPL statements are essential to the boot process and will need to be rolled back? Somewhere along the line you need to draw a boundary between what gets dealt with by snapper and what gets dealt with by the regular backup process. I would think that a system whereby pam_snapper took a snapshot of the user's workspace upon and only upon login, plus and changes that were saved (sort of like when you edit using VAX VMS) would be a lot more useful than the defaults we have now. Yes snapper on /boot and /lib/modules and /etc/ makes sense when you upgrade a kernel and it won't boot, but in the real world in a commercial setting, as a professional sysadmin, dealing with users who say "I deleted a file, Can I get it back?" is more realistic. I've been facing that as a sysadmin since the late in70s. And somewhere along the line this shifted to "But I can recover a deleted file on my MS-DOS (or later on, Windows) system, why can't I do that with UNIX/Linux?" Explaining about shared resource and someone else has since grabbed their discarded data block gets no sympathy. Every user is the centre of his own universe and that's all that matters to him/her. Just saying ... -- 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 2017-02-27 00:04, Anton Aylward wrote:
On 26/02/17 05:42 PM, Carlos E. R. wrote:
All /usr must be controlled by the snapshot-rollback mechanism.
I disagree.
There is no need for, for example, /usr/share/man and a lot more. it looks to me as if all of /usr/share can be excluded.
No, anything that comes in an rpm can be rolled back.
Yes snapper on /boot and /lib/modules and /etc/ makes sense when you upgrade a kernel and it won't boot, but in the real world in a commercial setting, as a professional sysadmin, dealing with users who say "I deleted a file, Can I get it back?" is more realistic.
That's a different scenario. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26/02/17 06:33 PM, Carlos E. R. wrote:
No, anything that comes in an rpm can be rolled back.
Think about that. its nonsense. I can put any files I want into a RPM. That doesn't justify them for being in a snapshot that can be rolled back. There are a lot of files on the system for which there's absolutely no point in saving in a snapshot, and they came in a RPM. If you look at the utility 'bleachbit', it has the ability to delete a lot of things that came in RPMs and good riddance to them! -- 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 2017-02-27 01:05, Anton Aylward wrote:
On 26/02/17 06:33 PM, Carlos E. R. wrote:
No, anything that comes in an rpm can be rolled back.
Think about that. its nonsense.
Well, you argue that with the devs. :-P The rollback feature works, and it is a fact that it needs control of the root filesystem, with many directories. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26/02/17 07:18 PM, Carlos E. R. wrote:
The rollback feature works, and it is a fact that it needs control of the root filesystem, with many directories.
stop and think for a moment what you mean by the term "root filesysrem". My root file systems excludes, has always excluded, /home and /tmp. To simplify upgrades, and to preserve data across upgrades, as well as principles of good functional compartmentalization, never mind efficiency and management of such things as backups, I also have separated out things that are clearly data, the FS for the web site(s), the FS for the SQL database. The SQL database? Well depending... Sometimes that's implemented as a separate file for each table, separate file for each index. on other implementations its implemented as a single big file that is managed as a whole by the DBMS. In the latter case, snapshotting the while file for a single change in a single table is going to be expensive! All in all I look to the dynamics and the value of using snapper vs conventional daily backup vs thin provisioning. I consider the operational processes involved. For example, I can upgrade 13.2 to LEAP by creating a new LVM logical volume for the RootFS, keeping, for example, my old /home and /srv (as well as /tmp that I just reformat) around[1]. If LEAP fails I just go back to using /dev/vgmain/vROOT132 rather than /dev/vgmain//vROOR421 I keep telling people "Context is Everything". There are no absolutes. [1] Heck, there is a lot of free LVM space in this multi-terabyte drive! -- 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 2017-02-27 01:53, Anton Aylward wrote:
On 26/02/17 07:18 PM, Carlos E. R. wrote:
The rollback feature works, and it is a fact that it needs control of the root filesystem, with many directories.
stop and think for a moment what you mean by the term "root filesysrem".
My root file systems excludes, has always excluded, /home and /tmp.
Sigh. I know, btrfs rollback also excludes /home. I said so. /tmp I'm unsure. The feature simply has a list of "volumes", some are included in rollback and some not. That's why you see a huge list of mounts on a default openSUSE system. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26/02/17 07:57 PM, Carlos E. R. wrote:
I know, btrfs rollback also excludes /home. I said so. /tmp I'm unsure.
Ah. Now you're talking about sub-volumes whereas I've been talking about mounted file systems. If I'm willing to edit the config file(s) for snapper then I can exclude anything. Or, as I said, I can set up snapper to work in an additional file system, REAL file system that is, not a sub-volume. Just like everything else about Linux, if you know what you're doing you can hand-craft the config files to make it do just about anything. Forget Yast. Yast is for doing things the designers of yast decided they thought you should be doing. Learn you system. Experiment. Break it a few (dozen/hundred) times. You learn more by making mstakes. -- 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 2017-02-27 02:09, Anton Aylward wrote:
On 26/02/17 07:57 PM, Carlos E. R. wrote:
I know, btrfs rollback also excludes /home. I said so. /tmp I'm unsure.
Ah. Now you're talking about sub-volumes whereas I've been talking about mounted file systems.
Doesn't matter. For excluded directories, doesn't matter.
If I'm willing to edit the config file(s) for snapper then I can exclude anything. Or, as I said, I can set up snapper to work in an additional file system, REAL file system that is, not a sub-volume.
No. Everything that snapper can rollback has to be, apparently, a single filesystem, with different volumes or whatever is the name.
Just like everything else about Linux, if you know what you're doing you can hand-craft the config files to make it do just about anything. Forget Yast. Yast is for doing things the designers of yast decided they thought you should be doing.
Learn you system. Experiment. Break it a few (dozen/hundred) times. You learn more by making mstakes.
Well, if you wish to spend time in that... I don't. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 27/02/17 00:57, Carlos E. R. wrote:
The feature simply has a list of "volumes", some are included in rollback and some not. That's why you see a huge list of mounts on a default openSUSE system.
Which is a fscking pain in the behind ... :-) Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-27 16:17, Wols Lists wrote:
On 27/02/17 00:57, Carlos E. R. wrote:
The feature simply has a list of "volumes", some are included in rollback and some not. That's why you see a huge list of mounts on a default openSUSE system.
Which is a fscking pain in the behind ... :-)
Yes, I agree. It is a pain when upgrading the system, see release notes. The user has to manually change/delete/create volumes. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Le 27/02/2017 à 00:04, Anton Aylward a écrit :
On 26/02/17 05:42 PM, Carlos E. R. wrote:
All /usr must be controlled by the snapshot-rollback mechanism.
I disagree.
There is no need for, for example, /usr/share/man and a lot more. it looks to me as if all of /usr/share can be excluded.
depends what you mean. If I get well what is done (not sure), only the changed files are included in a new snapshot, the others are untouched and so also untouched by the revert even more booting an older snapshot do *not* remove any file of the new one that said, when you do a new install even unchanged files (in rmp) may have a different date and how can you know if it's really unchanged? jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 27/02/17 03:24 AM, jdd wrote:
that said, when you do a new install even unchanged files (in rmp) may have a different date and how can you know if it's really unchanged?
For many of the example I gave its as matter of 'why should you care?" Let me put it this way: If I use bleachbit to clear out the 'COPYING'/GPL files, th3 language files I don't and am never going to use, then a global restore just means I'm going to use bleachbit to remove them *again*. Yes, Carlos, i know, since I'm savvy about config, having read man pages diligently and experimented (how else do you learn?) that I can exclude them. But for a lot of issues of simplicity, management, and other matters (see 'parallelism') I choose, and I think its a sound and more flexible strategy, to implement as a mounted file system. heck, we already do that for /home. Sime things I want to survive an update, and un-mounting them is a simple and reliable way to achieve that! -- 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 26/02/17 05:42 PM, Carlos E. R. wrote:
All that comes in rpms needs be included, because it can be reverted.
Some things, as I've said, should be set read only. In my opinion things like /usr/share/man and /usr/share/doc, which is so full of the GLPS (read some 'COPYING' files there) aren't going to change arbitrarily. Yes, they all come from RPMs. So what? And don't forget that there are a lot of places where an 'update' will not change the file. Many config files are like that, a new "<filename>.rpmnew" is created or perhaps the old is saved as "<filename>.rpmsave". Run # find /etc -name '*.rpm*' and see if you get some. Try it on /usr/share as well. -- 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 2017-02-27 00:08, Anton Aylward wrote:
On 26/02/17 05:42 PM, Carlos E. R. wrote:
All that comes in rpms needs be included, because it can be reverted.
Some things, as I've said, should be set read only. In my opinion things like /usr/share/man and /usr/share/doc, which is so full of the GLPS (read some 'COPYING' files there) aren't going to change arbitrarily. Yes, they all come from RPMs. So what?
That the design is to be able to revert *everything* that came in an install.
And don't forget that there are a lot of places where an 'update' will not change the file. Many config files are like that, a new "<filename>.rpmnew" is created or perhaps the old is saved as "<filename>.rpmsave".
Yes, I know that. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26/02/17 06:35 PM, Carlos E. R. wrote:
That the design is to be able to revert *everything* that came in an install.
Some of which might be neither needed nor desired. See my earlier mention. -- 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 2017-02-27 14:22, Anton Aylward wrote:
On 26/02/17 06:35 PM, Carlos E. R. wrote:
That the design is to be able to revert *everything* that came in an install.
Some of which might be neither needed nor desired. See my earlier mention.
Not the general case, but only yours. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 27/02/17 08:55 AM, Carlos E. R. wrote:
Not the general case, but only yours.
And judging by other posts, other threads, other history, a lot of other people will want such 'exceptions'. The whole point of Linux is to escape from the 'there's only one way to do it and that's the way we prescribe' attitude of other OS (and, for that matter, application) vendors. -- 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 26/02/17 19:22, Carlos E. R. wrote:
> There are excellent reasons to have /tmp and /var each on separate file > system/partitions,
Not when you use btrfs. You need them on the same partition for snapshots to work.
No you don't Yes, you absolutely do. If you want the rollback mechanishm on boot to work, you do. And it is not me who said that.
You can have snapshots, yes, but not the rollback feature on boot. The ability to boot an older snapshot, then make it the current one. "/" must be a single partition.
Any system that does that does not comply with the LFS. Which states that ANYTHING in /tmp is not guaranteed to survive a reboot. Okay, these are my gentoo systems, but /tmp is a massive /tmpfs, for precisely that reason (as is /var/tmp/portage). You can't have /var/tmp as a tmpfs and be LFS-compliant, as that is where apps are supposed to store their crash-recovery files etc. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 18:04, Dr.-Ing. Dieter Jurzitza wrote:
Hello Carlos, I am quite astonished what a reaction has been triggered by my writing. To comment what Carlos has been saying: I usually have a partition setup with /boot, / and /home as separate partitions.
Well, having a separate /boot with btrfs breaks the snapshot feature. You no longer can boot a previous version. Yes, the reaction happens because there is no consensus.
Because / does not change significantly there is IMHO no real need for it to be that large, 50 GByte - 100 GByte should be more than sufficient.
If that is inappropriate with btrfs - well, I'd say again, then this fs is not appropriate for the things a normal user would do. In my mind 50 GByte - 100 GByte are more than enough for a root file system, where usually nothing happens but a little writing to and from /tmp and /var/tmp.
Well, if you want snapshots you have to give space for them. That alone is no reason to discard btrfs. Not having the disk space can be a reason to not using snapshots. I understand than below some size the feature is disabled. As I said, some people had their day saved by snapshots. It is a very nice feature. People that know very little about Linux, novices. In my opinion, you should dedicate triple the normal space to "/". 100 GB seems enough. Maybe I would use 200, knowing that I like to install many things.
"The music plays" in /home, what I'd make as big as possible. And, +1 for the comments of Carlos with regard to btrfsck - if using it breaks the file system, then it should nor be distributed neither installed.
Right. But fsck.btrfs is mandatory. If it breaks or breaks the filesystem, the tool should be repaired before setting btrfs as the default filesystem. Repairing a filesystem should be easy, so easy as not to need help from others (the computer is broken, maybe no access to help). There can be exceptions, but should be rare. Consider Windows. People have been able to run "checkdisk" since the origin of times. It runs on boot if needed and repairs the disk. Rarely people have to click somewhere. But yes, I have seen breakage in ntfs that the default tool failed to repair and I had to buy a third party tool. This is not Windows, but the ease of use and reliability of the repair tool should be similarly good at least.
A regular approach is to check a filesystem with XXXfsck, and it is the very responsibility of that tool to not destroy anything and to guide you through problems if problems are found.
Yes.
At the end of the das I would like to rise the question again: "btrfs has new and interesting features". Well, for whom? Am I offered a car with 5 rather than 4 wheels now? Does this help me getting better from location A to location B?
I really love the snapshot capability. I do. But I'm not prepared to pay for it. I am afraid of using btrfs. The fright wins. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 26/02/17 01:09 PM, Carlos E. R. wrote:
I really love the snapshot capability. I do. But I'm not prepared to pay for it. I am afraid of using btrfs. The fright wins.
As I've said, there are a couple of ways of doing snapshots with LVM, one of them makes use of snapper as well. The bottom line is that you can have snapper-style backup-snapshots without BtrFS using ext4 or ResierFS. -- 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
Am Sonntag, Februar 26, 2017 18:04 CET, "Dr.-Ing. Dieter Jurzitza" <dieter.jurzitza@t-online.de> schrieb:
[...] I usually have a partition setup with /boot, / and /home as separate partitions.
[...]50 GByte - 100 GByte should be more than sufficient.
If that is inappropriate with btrfs - well, I'd say again, then this fs is not appropriate for the things a normal user would do.[...]
There was once a time when ext4 was where btrfs is now: How on earth would anyone use it when ext2 "just works"? Right? Right? :-) New technology comes with new features, new solutions and new ... surprises. I rarely had problems with btrfs (meaning: never lost data). I just ran once into "disk full" which made me pull my hair until I understood the issue. Btrfs in 2017 has left it's bugs behind (bug == data loss). It's now in the phase where a lot of people have to use it so the "strange" behaviors can be ironed out (like that a disk can be 90% full after deleting all files on it, thanks to snapshots). Some of those behaviors are due to tools. "df" is supposed to tell you how much disk space is left. Is data in a hidden snapshot "free disk space"?
From the point of a user: no. See can't write to the disk anymore, so hidden data is definitely not free disk space.
From the point of "df"? Yes, it is. Proof: If you collect all files and sum their sizes, which value do you expect?
So the old tools (which work well with extX fs) don't work so well with the new technology. That doesn't make the new technology bad. It's more like you having a hammer to fix things and you need to fix a computer. *Sometimes* the hammer is enough even though an expert would freak out. A better solution would be to patch "df" to show two values (10% full (50% incl. snapshots)). We wouldn't figure that out without giving btrfs to many people who then scream bloody hell at the decisions which seemed reasonable to designers. Or maybe the disk tools should print "this is a btrfs filesystem; please use btrfsctl instead". Lastly, btrfsctl should be more approachable. Some of the output is hard to understand (is this good or bad? if I change that, will that help or hurt?).
At the end of the das I would like to rise the question again: "btrfs has new and interesting features". Well, for whom? Am I offered a car with 5 rather than 4 wheels now? Does this help me getting better from location A to location B?
In this case, btrfs has a feature where you can rewind time to before the accident. Is that useful? Yes. For many people? Oh, yes! Hard to find? Maybe. Can it confuse even experts? Sure. Is it a bug? ... No. Is it better than ext4? Depends. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-27 11:03, Aaron Digulla wrote:
Am Sonntag, Februar 26, 2017 18:04 CET, "Dr.-Ing. Dieter Jurzitza" <> schrieb:
[...] I usually have a partition setup with /boot, / and /home as separate partitions.
[...]50 GByte - 100 GByte should be more than sufficient.
If that is inappropriate with btrfs - well, I'd say again, then this fs is not appropriate for the things a normal user would do.[...]
There was once a time when ext4 was where btrfs is now: How on earth would anyone use it when ext2 "just works"? Right? Right? :-)
Well, as far as I remember the issues with ext4 didn't last long, whereas btrfs is still problematic after all this time. Sure, it is more advanced.
New technology comes with new features, new solutions and new ... surprises. I rarely had problems with btrfs (meaning: never lost data). I just ran once into "disk full" which made me pull my hair until I understood the issue.
I did lose test data. Ie, not real data, but I managed to crash the filesystem beyond repair. The crash was repeatable. This particular issue has been solved since.
A better solution would be to patch "df" to show two values (10% full (50% incl. snapshots)). We wouldn't figure that out without giving btrfs to many people who then scream bloody hell at the decisions which seemed reasonable to designers.
Yes, I think df should be patched to give info pertinent to btrfs, perhaps after giving an option, if the change would break scripts that parse result.
At the end of the das I would like to rise the question again: "btrfs has new and interesting features". Well, for whom? Am I offered a car with 5 rather than 4 wheels now? Does this help me getting better from location A to location B?
In this case, btrfs has a feature where you can rewind time to before the accident. Is that useful? Yes. For many people? Oh, yes! Hard to find? Maybe. Can it confuse even experts? Sure. Is it a bug? ... No. Is it better than ext4? Depends.
Yes, I agree it is a very useful feature. I simply do not trust it. Also, on practical reasons, I would have to repartition my disks to give way more space to the root partition, and I'm not doing that work anytime soon. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 02/27/2017 02:03 AM, Aaron Digulla wrote:
There was once a time when ext4 was where btrfs is now: How on earth would anyone use it when ext2 "just works"? Right? Right?:-)
Yes, I remember those times, and I didn't use ext4 then either! I was rather fond of Reiserfs. Linux is all about choice.
New technology comes with new features, new solutions and new ... surprises. I rarely had problems with btrfs (meaning: never lost data). I just ran once into "disk full" which made me pull my hair until I understood the issue.
FWIW, I was able to reliably and permanently damage btrfs filesystems on raid partitions exceeding 16-TB. This was a few years ago, and yes, I submitted a bug report. I didn't loose any real data, those were test scenarios. For the past couple of years I've been using ext4 on /, xfs on data partitions for production systems. Is it time for me to try btrfs again on large partitions? What are the advantages over xfs on partitions up to 210-TB? Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 26 February 2017 at 18:04, Dr.-Ing. Dieter Jurzitza <dieter.jurzitza@t-online.de> wrote:
Hello Carlos, I am quite astonished what a reaction has been triggered by my writing. To comment what Carlos has been saying: I usually have a partition setup with /boot, / and /home as separate partitions.
Because / does not change significantly there is IMHO no real need for it to be that large, 50 GByte - 100 GByte should be more than sufficient.
If that is inappropriate with btrfs - well, I'd say again, then this fs is not appropriate for the things a normal user would do. In my mind 50 GByte - 100 GByte are more than enough for a root file system, where usually nothing happens but a little writing to and from /tmp and /var/tmp.
"The music plays" in /home, what I'd make as big as possible. And, +1 for the comments of Carlos with regard to btrfsck - if using it breaks the file system, then it should nor be distributed neither installed.
A regular approach is to check a filesystem with XXXfsck, and it is the very responsibility of that tool to not destroy anything and to guide you through problems if problems are found.
from btrfsck (aka "btrfs check") --help "WARNING: the repair mode is considered dangerous" from man btrfs check "Warning Do not use --repair unless you are advised to by a developer, an experienced user or accept the fact that fsck cannot possibly fix all sorts of damage that could happen to a filesystem because of software and hardware bugs." from man e2fsck (aka fsck.ext2/3/4) " Note that in general it is not safe to run e2fsck on mounted filesystems. The only exception is if the -n option is specified, and -c, -l, or -L options are not specified. However, even if it is safe to do so, the results printed by e2fsck are not valid if the filesystem is mounted. If e2fsck asks whether or not you should check a filesystem which is mounted, the only correct answer is ``no''. Only experts who really know what they are doing should consider answering this question in any other way." from man xfs_repair " The filesystem to be checked and repaired must have been unmounted cleanly using normal system administration procedures (the umount(8) command or system shutdown), not as a result of a crash or system reset. If the filesystem has not been unmounted cleanly, mount it and unmount it cleanly before running xfs_repair" " xfs_repair does not do a thorough job on XFS extended attributes. The structure of the attribute fork will be consistent, but only the contents of attribute forks that will fit into an inode are checked. This limitation will be fixed in the future. " "The no-modify mode (-n option) is not completely accurate. It does not catch inconsistencies in the freespace and inode maps, particularly lost blocks or subtly corrupted maps (trees). The no-modify mode can generate repeated warnings about the same problems because it cannot fix the problems as they are encountered. If a filesystem fails to be repaired, a metadump image can be generated with xfs_metadump(8) and be sent to an XFS maintainer to be analysed and xfs_repair fixed and/or improved." The conclusion you can take from the above is that all fsck tools are somewhat unsafe, all should be taken with some care and btrfs is the only one which clearly documents this fact not only in it's man page, but also at runtime in the command. Which is the more responsible tool as a result? e2fsck? I think not.
At the end of the das I would like to rise the question again: "btrfs has new and interesting features". Well, for whom? Am I offered a car with 5 rather than 4 wheels now? Does this help me getting better from location A to location B?
I would expect that distribution maintainers are very very careful when it comes to changing the basic basic infrastructure of a system - and, in this case I see no good reason for this to be done. Something new is not neccessarily good, newness is no positive attribute as such, and when the only _siginificant_*) difference can be reduced to "because it is new", then there is no sense in the switch - IMHO, as always. And, something old in turn is not neccessarily bad simply because it is old.
The most reliable elements in a linux systems are the tools like "dd", "tar", "ls" and so on and so forth.
The answer to your question is so simple I'm surprised I have to explain it, but here goes. Consider the key benefits of openSUSE Tumbleweed and Leap Tumbleweed - a rolling distribution you can rely on Leap - an enterprise-based distribution including fully integrated with community packages Regarding Tumbleweed - despite all the magic we have in OBS and openQA, there is always the risk that a rolling update could break something, or at least change something in a way that a user is not expecting. In that case, you need a system to be able to magically revert anything so you can go back to a last known good, trusted state. ie. you need root filesystem snapshots ie. you need snapper and btrfs therefore, btrfs is the default root filesystem for Tumbleweed. Regarding Leap - enterprise linux are not rolling, but they are using their enterprise linux in environments where the shortest outages can cause millions of dollars of lost revenue. In that case, you need a system to be able to magically revert anything done by the sysadmin or by the software vendor to a last known good, trusted state. ie. you need root filesystem snapshots ie. you need snapper and btrfs therefore, btrfs is the default root filesystem for SUSE Linux Enterprise Leap is based on SUSE Linux Enterprise therefore btrfs is the default root filesystem for openSUSE Leap You may be neither a rolling user nor an enterprise one, but for years the openSUSE Project has had countless of its users lobbying for a regular release distribution with more stability like an enterprise distribution, a release schedule more like an enterprise distribution, and a feature set that at least matches an enterprise distribution. With Leap you get that, plus extra, which means adopting standard tooling and features which are now expected in enterprise settings. This might mean a little more education, study, and care is required. But we haven't rushed into this, it shouldn't be a surprise, btrfs has been around in openSUSE for years now, and the default for years also. You were given a fair opportunity to learn and get used to these new technologies in advance, you still have an opportunity to catch up, but requesting a reversion to something which is a key part of both of openSUSE's main distribution offerings is unlikely to get traction. Especially as you do not appear to be volunteering to do any of the work, just asking others to do it for you..why should our maintainers discard they work they've been doing just because it doesn't suit you? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-27 13:04, Richard Brown wrote:
On 26 February 2017 at 18:04, Dr.-Ing. Dieter Jurzitza <> wrote:
A regular approach is to check a filesystem with XXXfsck, and it is the very responsibility of that tool to not destroy anything and to guide you through problems if problems are found.
from btrfsck (aka "btrfs check") --help
"WARNING: the repair mode is considered dangerous"
Unacceptable.
from man btrfs check
"Warning Do not use --repair unless you are advised to by a developer, an experienced user or accept the fact that fsck cannot possibly fix all sorts of damage that could happen to a filesystem because of software and hardware bugs."
unacceptable.
from man e2fsck (aka fsck.ext2/3/4)
" Note that in general it is not safe to run e2fsck on mounted filesystems.
Of course. A filesystem can only be repaired if not mounted - even on Windows.
from man xfs_repair
" The filesystem to be checked and repaired must have been unmounted cleanly using normal system administration procedures (the umount(8) command or system shutdown), not as a result of a crash or system reset. If the filesystem has not been unmounted cleanly, mount it and unmount it cleanly before running xfs_repair"
Same thing, umounted. No surprise. And the log must be played.
The conclusion you can take from the above is that all fsck tools are somewhat unsafe, all should be taken with some care and btrfs is the only one which clearly documents this fact not only in it's man page, but also at runtime in the command.
All those tools for other filesystems do work as they say they do. They don't make things worse, in any case. And in most cases, they do repair the damage.
Especially as you do not appear to be volunteering to do any of the work, just asking others to do it for you..why should our maintainers discard they work they've been doing just because it doesn't suit you?
Oh, but the volunteers have to be aware of what the users want and really use. Just by they volunteering to do something the way they like doesn't mean that others have to accept that work without critique. That doesn't mean the work invested is not appreciated. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 27/02/17 07:04 AM, Richard Brown wrote:
from man btrfs check
"Warning Do not use --repair unless you are advised to by a developer, an experienced user or accept the fact that fsck cannot possibly fix all sorts of damage that could happen to a filesystem because of software and hardware bugs."
I am puzzled by all this. What's the point in shipping a file system if you can't supply the tools so that end users can perform maintenance on them? In effect what this saying is that the file system is unreliable because it can't be maintained or repaired except by the developers. And, lets face it, developers are just, to quote Doug Adams, regular guys. They have lives apart from being on 24/7 alert for Linux users who have borked their file system and need a developer to repair it for them. Thank you, Richard, for brining to our attention this damning indictment of BtrFS. Now we all know better than to install something that can't be maintained by us 'regular guys'. Richard, you go on to make an excellent case for the use of BtrFS in a commercial/industrial setting where the corporation can pay for support. And I agree with that, having worked in such establishments. Your arguments are fully justified. But for the regular home users, the 'Joe six-pack', the people converting from MS-Windows because Microsoft has finally pizzed them off, the people setting up a basic email&browser for grandmother (yes, I know, she should have been given a ChromeBook for Christmas!), its quite another matter. -- 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
The first thing I do with any filesystem that I suspect is broken, is fsck it. Always. On some, like XFS, that program does nothing...
fsck.btrfs also does absolutly nothing: https://btrfs.wiki.kernel.org/ index.php/Manpage/fsck.btrfs if your going to use btrfs specific tools like btrfs check, you should find out how it works first. from wikipedia fsck: Full copy-on-write file systems such as ZFS and Btrfs are designed to avoid most causes of corruption and have no traditional "fsck" repair tool. Both have a "scrub" utility which examines and repairs any problems; in the background and on a mounted filesystem. hitting your lcd monitor cause it used to work on your cathode ray tube comes to mind. does anyone have any statistics for the number of btrfs check corruptions to know what were arguing about? 1 in 100, 1 in 10,000? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-27 16:13, nicholas wrote:
The first thing I do with any filesystem that I suspect is broken, is fsck it. Always. On some, like XFS, that program does nothing...
fsck.btrfs also does absolutly nothing: https://btrfs.wiki.kernel.org/ index.php/Manpage/fsck.btrfs
minas-tirith:~ # cat /usr/sbin/fsck.btrfs #!/bin/sh -f # # Copyright (c) 2013 SUSE # # copied from fsck.xfs # Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved. # # fsck.btrfs is a type of utility that should exist for any filesystem and is # called during system setup when the corresponding /etc/fstab entries contain # non-zero value for fs_passno. (See fstab(5) for more.) # # Traditional filesystems need to run their respective fsck utility in case the # filesystem was not unmounted cleanly and the log needs to be replayed before # mount. This is not needed for BTRFS. You should set fs_passno to 0. # # If you wish to check the consistency of a BTRFS filesystem or repair a # damaged filesystem, see btrfs(8) subcommand 'check'. By default the # filesystem consistency is checked, the repair mode is enabled via --repair # option (use with care!). AUTO=false while getopts ":aApy" c do case $c in a|A|p|y) AUTO=true;; esac done shift $(($OPTIND - 1)) eval DEV=\${$#} if [ ! -e $DEV ]; then echo "$0: $DEV does not exist" exit 8 fi if ! $AUTO; then echo "If you wish to check the consistency of a BTRFS filesystem or" echo "repair a damaged filesystem, see btrfs(8) subcommand 'check'." fi exit 0 minas-tirith:~ # It looks to me copied from the XFS utility, with the difference than the later was created upstream.
if your going to use btrfs specific tools like btrfs check, you should find out how it works first.
Actually, most tools do a check and advise what to do next.
from wikipedia fsck: Full copy-on-write file systems such as ZFS and Btrfs are designed to avoid most causes of corruption and have no traditional "fsck" repair tool. Both have a "scrub" utility which examines and repairs any problems; in the background and on a mounted filesystem.
hitting your lcd monitor cause it used to work on your cathode ray tube comes to mind.
does anyone have any statistics for the number of btrfs check corruptions to know what were arguing about? 1 in 100, 1 in 10,000?
I created one partition and crashed it beyond repair on my stress test. The bug was solved, but took some long time. So, for me it was 100% casualties. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 27 February 2017 at 15:29, Anton Aylward <opensuse@antonaylward.com> wrote:
On 27/02/17 07:04 AM, Richard Brown wrote:
from man btrfs check
"Warning Do not use --repair unless you are advised to by a developer, an experienced user or accept the fact that fsck cannot possibly fix all sorts of damage that could happen to a filesystem because of software and hardware bugs."
I am puzzled by all this. What's the point in shipping a file system if you can't supply the tools so that end users can perform maintenance on them?
In effect what this saying is that the file system is unreliable because it can't be maintained or repaired except by the developers.
And, lets face it, developers are just, to quote Doug Adams, regular guys. They have lives apart from being on 24/7 alert for Linux users who have borked their file system and need a developer to repair it for them.
Thank you, Richard, for brining to our attention this damning indictment of BtrFS.
Now we all know better than to install something that can't be maintained by us 'regular guys'.
Richard, you go on to make an excellent case for the use of BtrFS in a commercial/industrial setting where the corporation can pay for support. And I agree with that, having worked in such establishments. Your arguments are fully justified.
But for the regular home users, the 'Joe six-pack', the people converting from MS-Windows because Microsoft has finally pizzed them off, the people setting up a basic email&browser for grandmother (yes, I know, she should have been given a ChromeBook for Christmas!), its quite another matter.
To be blunt- Anton, if you think that fsck is the only tool you need to performance maintenance of btrfs or any other filesystem, then you are a bloody idiot btrfs scrub is what people should be using as an analogy of "fsck" in the btrfs world If you took the time to do a tiny bit of homework, or read the 3rd line of the URL I provided at the beginning of the thread you'd know this already. It's safe, can be run regularly, automatically reads data and metadata blocks, verifies checksums and repairs automatically But that's not all, btrfs has more tools in its toolbox for maintenance, such as "btrfs filesystem defragment" and "btrfs balance". There is no case for a damning indictment of btrfs and only an imbecile would look at the reality of the tooling available and come to that conclusion. So get off your bloody high horse and stop wasting everyone's time on this mailinglist with your ceaseless verbal diarrhoea. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 27/02/17 10:29 AM, Richard Brown wrote:
To be blunt-
Anton, if you think that fsck is the only tool you need to performance maintenance of btrfs or any other filesystem, then you are a bloody idiot
"Only"? No, no way. but then I'm quite experienced and can probably make use of a bit-level editor if I have to. I'm also well aware of the tools to work with not just BtrFS but XFS and the ext-family. But before you go much further, knowing how to use a tool to repair something and knowing to the create it in the first pace are two different things. My car mechanic can fix my car but he can't mine ore, make steel, make plastic, make semiconductors, etc etc. Don't ask me to code a FS or contribute code or patches. A lot of the time I can't even wolf-fence a bug well enough to consistently reproduce it for a detailed bug report. But that's all quite beside the point. As I've pointed out there is a need for Industrial Grade things in a high end commercial setting. There's a gap between, even for Microsoft, between the home user and what is needed in a bank or brokerage. And I've spent a great deal of my working life with Big Iron and with AIX and HP/UX in banks. Joe-sixpack, your grandmother, high-school students and the like can't afford that kind of computing. Never mind that we're on the verge of computing technology that can put yesterdays supercomputer in your cellphone tomorrow. Mass production and commercial marketing means there is always going to be a gap. These 'consumers' need something that 'just works', they can't afford the time out for the training and experience that people like Thee&Mee and Carlos have. This thread began with a regular user who just expected his system to work ... and it didn't. Already Carlos has pointed out that even he is unwilling to do what I've done and experiment and push limits and break the system just to see what you can do with it. What can you expect of the grandmothers? You are calling me the 'bloody idiot' when I'm one of the people who do take things apart to see how they work, try alternatives. I've just not a coder. Berate me, but I'm saying this as a 'proxy' for the people who don't have out experience and skills and just wants a system that works. Its doable: my cell phone 'just works'. Well most of the time :-) But a system that's geared for the kind of reliable operation in the context of bank (etc) with trained sysadmins (BTDT, was on 24/7 with a pager etc) is different from a home PC. Microsoft were well aware of this. You go on about the tools and features of BtrFS as if you were selling it. That's fine, tell them to the VPIT & his Chosen Ones like the guys at SUSE do in their marketing presentations. I've seen them. They say the same kind of thing, have it well scripted, along with a power-point presentation. There's a similar one for developers. But its irrelevant to the Joe-Sixpack and the grandmothers, its jut hi-tech bafflegab to them. Oh, I'm sure they believe you when you say that its and advantage. But they don't have the skills, experience, technical education and training that the Likes of Thee&Mee&Carlos have to be able to make use of these tools, the decide which is appropriate in what context as we can. This is not the 'damning indictment' of BtrFS that you seem to think I'm making. I've said before and I'll keep saying, "Context is Everything". There are a whole pile of contexts for which BtrFS, snapper, makes a lot of sense and is eminently the right choice. And for many individuals, and I refer to the OP of this thread as one, for which it is not. There's very little in this world that is "one size fits all". Part of what Linux offers, ha always offered, is 'choice'. As Larry Wall pointed out, there's always another way to do it, and that other way be more suitable in a specific context. All that being said, I'm in a similar situation to Carlos. I started using BtrFS in the early days, had problems with some earlier bugs that are now fixed. I've met and tried all those tools you go on about, Richard. I have no complaints about BtrFS as BtrFS. I just don't think it should be a default for home systems but rather offered as a choice just as ReiserFS, NilFS2 and others are FOR SUITABLE CONTEXT AND PEOPLE WHO UNDERSTAND THEIR CONTEXTUAL BENEFITS. One example of this is something that is important to me: dynamic provisioning. ReiserFS has it. XFS has it. BtrFS has it. Ext4 does not. So, guess which file systems I use and which I don't. If, perhaps, a hypothetical ext5 extends the B-tree mechanisms of ext4 to get away from the fixed allocation of inode blocks vs data blocks that has been around since UNIX v6 and before then I might experiment with that and if it turns out to be reliable replace my ReiserFS with that. BIG MAYBE, eh? -- 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 27/02/17 09:29 AM, Anton Aylward wrote:
I am puzzled by all this.
Con someone confirm for me please... Its a long long time since I had a problem with my BrtFS ROOTFS, or, for that matter, any of my ReiserFS partitions.... But I seem to recall that when booting the kernel tried to mount a FS and if it fails it runs a FSCK to try and fix it. Is my recollection incorrect? ================================================================================ So if the ROOTFS won't mount and the FSCK does nothing to fix it, what happens? Now I personally don't see that as a problem. Back in the early days when it happened to me I used the RESCUE disk and tools to repair the ROOTFS. Annoying and frustrating, but as they say "it was a learning experience". And I'm still running BtrFS as my ROOTFS. But I wonder about the OP of this thread. He seems to be in the position I was in back then. But I have a little more confidence in the developers. I trust them to be smarter than me (I've found this to be a good rule of thumb) and supplied tools and yes they did and I studied matters and with a bit of experimentation and misunderstanding on my part got the BtrFS fixed and rebooted. A couple of kernel upgrades later the structure of the FS changed and that version of the RESCUE disk wouldn't have worked any more, but the change made BtrFS faster and certainly more reliable. Updates are worth it :-) -- 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 2017-02-27 19:38, Anton Aylward wrote:
On 27/02/17 09:29 AM, Anton Aylward wrote:
I am puzzled by all this.
Con someone confirm for me please...
Its a long long time since I had a problem with my BrtFS ROOTFS, or, for that matter, any of my ReiserFS partitions....
But I seem to recall that when booting the kernel tried to mount a FS and if it fails it runs a FSCK to try and fix it.
Is my recollection incorrect?
Partly. If the filesystem can not be mounted, it panics. You get into emergency console - for root failing, that would be from the initram, I guess. The best thing is to boot proper rescue media, but openSUSE no longer creates the rescue ISO. There is just a very small rescue system in the install DVD. Very minimal. The automatic fsck is run when the system was not properly halted the previous time. Applies to ext* and reiserfs, not xfs or btrfs. In the case of ext*, also is done periodically. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Hello Richard, take a kind look i. e. here 1017461* (bugzilla of openSUSE, quite new): Given the risk I repeat myself: I haven't seen a anyhow comparable amount of FS problems for ext4 than for btrfs recently. Fact. You cannot argue on this. The net is full of such stories. I have seen issues on a bunch of computers I am maintaining, all related to btrfs. My personal experience. You can argue on this, but I would not rise my voice to just hear me talk. I haven't seen similar issues on ext4. Never. My machine runs 24 x 7 since years. And whatever you tell about nice "technology by powerpoint" stories about shiny theoretical features of btrfs: the problems I observe would not have occured in case ext4 would have been the default. And you don't have to argue about fsck'ing a filesystem that is mounted - I do not know how this came into this discussion, I would never do this and I have never done this. I am running leap, so do my friends and my family because we want a system to be useable not requiring extra maintenance. With a stable basis. You can provide tons of explanations, you can allegate to me whatever you want, I will keep saying that ext4 is the better choice for a "normal" user and therefore ought to be preferred. What big amount of work is introduced by simply switching the default choice in YaST and in the installer is not apparent for me. And, at the end of the day: making backups is mandatory anyhow, whether the system has a snapshotting option or not. That's about all what is to add here. Have a nice day Dieter Jurzitza *) I hear you already say this is not a btrfs problem. No, it is. Because if there was no btrfs, there was no such problem. btrfs is increasing system complexity because it comes with this and that tool, with this and that configuration, all increasing the risk to loose data at the end of the day. What in fact happens. -- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-27 20:40, Dr.-Ing. Dieter Jurzitza wrote:
And you don't have to argue about fsck'ing a filesystem that is mounted - I do not know how this came into this discussion, I would never do this and I have never done this.
Ditto, I don't know why it came. Just as curiosity, Windows can fsck its main partition during boot, dunno how, not sure if mounted or not (it doesn't have the concept). Linux checks root while booting, from the initrd, umounted as far as I know. We all know that to do a filesystem repair in Linux the partition has to be umounted. As to the rest you said, I agree. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Le 27/02/2017 à 22:56, Carlos E. R. a écrit :
Just as curiosity, Windows can fsck its main partition during boot, dunno how, not sure if mounted or not (it doesn't have the concept).
of course it does (but it's hidden). to check you can mount, but read only jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
+1 Am 26.02.2017 um 08:22 schrieb Dr.-Ing. Dieter Jurzitza:
Dear listmembers, dear openSUSE - maintainers, I maintain about 5 to 6 PC running (openSUSE) linux. My own, my sisters my friends ... Currently most of them are running with leap.
During the last month I had to reinstall _all_ of them. All with broken / inconsitent / strange behaving root Btrfs file systems.
After 25 years of working with linux I'd consider myself kind of experienced what regards linux problems.
And, if that had had happened once I would have said it has been my fault. I do not think so any more. I consider Btrfs instable and inappropriate for public usage.
I'd go further and would like to ask, *why* this is set as the default root fs when installing. This is totally inunderstandable to me after my experiences.
I never ever experienced any bit of advantage in comparison with ext4. But I experienced nights of work - just to restore a state that had had existed a few days before.
So, please, think it over:
*take Btrfs out as default!*
Use stable and well known systems as the foundation of public systems. Changing things only to change something is leading nowhere.
Besides, if there is a kind soul that can explain what was the reason for making Btrfs the default I would highly appreciate. I cannot see any change besides significantly improved stability when going back to ext4. The latter being the most important thing IMHO.
My two cents regards
Dieter Jurzitza
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dr.-Ing. Dieter Jurzitza wrote:
During the last month I had to reinstall _all_ of them. All with broken / inconsitent / strange behaving root Btrfs file systems.
I had some problems with btrfs too. Not a broken file system though. The system became unusable for about an hour. Had I waited long enough I might have seen responses on this list saying to remove quotas and check for bugs, but I re-installed the system with ext4. Luckily that only affects me and it only took an hour or two. I only have an 80 gig disk on this system, and I only had 20 gig for root. Snapshots were useful for retrieving the occasional file, but I never succeeded in booting from a snapshot. Always they were unbootable. I think it is difficult to judge what are the best installation defaults. Maybe it should suggest different settings for different types of user, and different available spaces. Part of the point of opensuse is to test things out for SUSE isn't it? Since re-installing with ext4 I find the system performs better on zypper updates and switching between users. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 26/02/17 12:20 PM, Richmond wrote:
[snip]
I only have an 80 gig disk on this system, and I only had 20 gig for root.
I have a laptop I still use that has a 80G drive. I set up with LVM and never used all of the 80G. It's a 32-but machine so I still run 13.2 on it. For the 'big stuff' I use NFS to my desktop, but for a machine out of the house, writing, browsing, email, its more than adequate. I only *need* the powerful (by comparison) 64-bit desktop with the wide screen for things like photediting. heck, for many things, browsing the web, news reading, book reading, email, the Android tablet is perfectly adequate and I can use that on the patio. its a lot lighter than the laptop to and more handleable.
Snapshots were useful for retrieving the occasional file, but I never succeeded in booting from a snapshot. Always they were unbootable.
Regular readers will recall that I'm a strong advocate of LVM. LVM lets you do snapshots in a number of ways. Simple LVM snapshots create an initially empty logical partition that only fills with copies of the files you change. But there is also a way to run 'snapper' with a thin partition type mirror using LVM. -- 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 Sunday, 26 February 2017 18:20:59 CET Richmond wrote:
Snapshots were useful for retrieving the occasional file, but I never succeeded in booting from a snapshot. Always they were unbootable.
i find it hard to believe that this was a technical failure on multiple occasions, can you describe what you mean by unbootable? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
nicholas wrote:
On Sunday, 26 February 2017 18:20:59 CET Richmond wrote:
Snapshots were useful for retrieving the occasional file, but I never succeeded in booting from a snapshot. Always they were unbootable. i find it hard to believe that this was a technical failure on multiple occasions, can you describe what you mean by unbootable?
The system would not boot. :) I can't remember exactly what happened. I could try and re-create it on another computer if you are really interested. . -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
nicholas wrote:
On Sunday, 26 February 2017 18:20:59 CET Richmond wrote:
Snapshots were useful for retrieving the occasional file, but I never succeeded in booting from a snapshot. Always they were unbootable.
i find it hard to believe that this was a technical failure on multiple occasions, can you describe what you mean by unbootable?
The system would not boot. :)
I can't remember exactly what happened. I could try and re-create it on another computer if you are really interested.
.
On Sunday, 26 February 2017 19:14:23 CET Richmond wrote: please do, i would wager there is something wrong with your setup or the grub sequence is very non-intuitive. the most i would expect is trouble with conficts on non restored drives (opt/home). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
nicholas wrote:
nicholas wrote:
On Sunday, 26 February 2017 18:20:59 CET Richmond wrote:
Snapshots were useful for retrieving the occasional file, but I never succeeded in booting from a snapshot. Always they were unbootable. i find it hard to believe that this was a technical failure on multiple occasions, can you describe what you mean by unbootable? The system would not boot. :)
I can't remember exactly what happened. I could try and re-create it on another computer if you are really interested.
.
On Sunday, 26 February 2017 19:14:23 CET Richmond wrote: please do, i would wager there is something wrong with your setup or the grub sequence is very non-intuitive. the most i would expect is trouble with conficts on non restored drives (opt/home).
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday, 26 February 2017 19:47:25 CET Richmond wrote:
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs. 100gb is not required, you would be fine on 30gb (for root only) if you keep an eye on things and change snapper defaults if required. 20 gb wouldnt work due to the way space is allocated.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sunday, 26 February 2017 20:06:39 CET Andrei Borzenkov wrote:
26.02.2017 21:53, nicholas пишет:
20 gb wouldnt work due to the way space is allocated.
What are you talking about?
from incomplete impressions: 1 - allocation - meta and data are over-allocated by design - allocated in minimal size units (256mb?) - units are rarely filled efficiently (hence the need for rebalance) this introduces an "overhead" on the use of free space you can run out of space on either meta or data whilst there is still free space on the other. 2 - interval cleanup: - quotas etc are activated on cron and so you can go over budget in short periods of time - balance is only performed intermitantly to summerize - you need 'some' extra free space '20 gb wouldnt work' was incorrect - '20gb would be tight' might have been better, mine works fine with 26gb. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 19:47, Richmond wrote:
nicholas wrote:
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs.
I don't remember which is the exact size. At that size or smaller snapshots are disabled. Could be 20, could be 15. Maybe in release notes? Not in Leap, just looked. Maybe some email. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
26.02.2017 21:47, Richmond пишет:
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs.
bor@bor-Latitude-E5450:~$ truncate -s 1M /var/tmp/btrfs bor@bor-Latitude-E5450:~$ mkfs.btrfs /var/tmp/btrfs btrfs-progs v4.4 See http://btrfs.wiki.kernel.org for more information. '/var/tmp/btrfs' is too small to make a usable filesystem Minimum size for each btrfs device is 41943040. My TW VM has 15G. Before it had 10G and went out of space on almost each update. With 15G it happens probably every fifth one, at which point I remove snapshots, probably run balance and resume update. I did not experience non-bootable system but I also do not really do anything in this VM, just boot it occasionally. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
26.02.2017 21:47, Richmond пишет:
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs.
bor@bor-Latitude-E5450:~$ truncate -s 1M /var/tmp/btrfs bor@bor-Latitude-E5450:~$ mkfs.btrfs /var/tmp/btrfs btrfs-progs v4.4 See http://btrfs.wiki.kernel.org for more information.
'/var/tmp/btrfs' is too small to make a usable filesystem Minimum size for each btrfs device is 41,943,040.
Isn't that 41.9 G? (I put the commas in). I searched the page but could not find the word "minimum". What am I looking for? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 20:05, Andrei Borzenkov wrote:
26.02.2017 21:47, Richmond пишет:
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs.
bor@bor-Latitude-E5450:~$ truncate -s 1M /var/tmp/btrfs bor@bor-Latitude-E5450:~$ mkfs.btrfs /var/tmp/btrfs btrfs-progs v4.4 See http://btrfs.wiki.kernel.org for more information.
'/var/tmp/btrfs' is too small to make a usable filesystem Minimum size for each btrfs device is 41943040.
No, it is not that. It is a policy used by YaST that disables snapshotting of btrfs filesystems smaller than certain size. Nothing to do with the minimum size for btrfs. I don't have a link for this, only my memory, sorry. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Le 26/02/2017 à 19:47, Richmond a écrit :
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs.
it works if you disable snapshots completely jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
26.02.2017 22:11, jdd пишет:
Le 26/02/2017 à 19:47, Richmond a écrit :
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs.
it works if you disable snapshots completely
Define "works". I have 15G with active snapper and this instance had 10G before. 10G was rather tight. 15G allows me to keep 4-5 snapshots before it goes out of space. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 26/02/2017 à 20:13, Andrei Borzenkov a écrit :
26.02.2017 22:11, jdd пишет:
Le 26/02/2017 à 19:47, Richmond a écrit :
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs.
it works if you disable snapshots completely
Define "works". I have 15G with active snapper and this instance had 10G before. 10G was rather tight. 15G allows me to keep 4-5 snapshots before it goes out of space.
I have an install where I had only 20Gb (24Gb ssd), I had to disable snapshots completely. After that I didn't have any more problem jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
jdd wrote:
Le 26/02/2017 à 19:47, Richmond a écrit :
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs.
it works if you disable snapshots completely
You can't boot from a snapshot if you disable snapshots. (Which is what this admittedly hijacked sub-thread is about). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 26/02/2017 à 20:24, Richmond a écrit :
jdd wrote:
Le 26/02/2017 à 19:47, Richmond a écrit :
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs.
it works if you disable snapshots completely
You can't boot from a snapshot if you disable snapshots. (Which is what this admittedly hijacked sub-thread is about).
that's obvious :-), I just mean you can keep btrfs jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 26/02/17 01:47 PM, Richmond wrote:
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs.
I'm running a BtrFS (ok, its 13.2 upgrading to Tumbleweed) ... # df / -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vgmain-vROOT 20G 9.5G 11G 49% / and # mount | grep btrfs /dev/mapper/vgmain-vROOT on / type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/) Sorry, I'm getting feed up with Carlos telling us/me that something can't be done when there are people, myself for example, doing it. -- 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 2017-02-26 20:18, Anton Aylward wrote:
On 26/02/17 01:47 PM, Richmond wrote:
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs.
No, I did not say that.
I'm running a BtrFS (ok, its 13.2 upgrading to Tumbleweed) ...
# df / -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vgmain-vROOT 20G 9.5G 11G 49% /
and
# mount | grep btrfs /dev/mapper/vgmain-vROOT on / type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)
Sorry, I'm getting feed up with Carlos telling us/me that something can't be done when there are people, myself for example, doing it.
because that is not what I said! I said that below certain root size YaST disables snapshotting. Not that it does not work. Of course, YaST does that for a reason: you have to be careful to erase old snapshots and make space. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
Carlos E. R. wrote:
On 2017-02-26 20:18, Anton Aylward wrote:
On 26/02/17 01:47 PM, Richmond wrote:
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs. No, I did not say that. OK I am sorry if I misunderstood. You said:
Carlos E. R. wrote:
On 2017-02-26 19:00, nicholas wrote:
On Sunday, 26 February 2017 18:20:59 CET Richmond wrote:
Snapshots were useful for retrieving the occasional file, but I never succeeded in booting from a snapshot. Always they were unbootable. i find it hard to believe that this was a technical failure on multiple occasions, can you describe what you mean by unbootable? It simply does not work at that size. I think the current default is to disable them.
So I took "that size" to be the size of the system we were discussing, i.e. 20g. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 20:32, Richmond wrote:
Carlos E. R. wrote:
On 2017-02-26 20:18, Anton Aylward wrote:
On 26/02/17 01:47 PM, Richmond wrote:
Carlos says it won't work on a 20G file system, so if that's the case there isn't any point in me trying. I can't find anything which officially says what the minimum file system size is for btrfs. No, I did not say that. OK I am sorry if I misunderstood. You said:
Yes, I don't think I explained it well. What I wanted to say is that YaST disables snapshots below certain size during the initial install. And I don't remember what size is that, it is not in the release notes for Leap. maybe 15 GB, maybe 20 GB... dunno. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On 2017-02-26 19:25, nicholas wrote:
On Sunday, 26 February 2017 19:14:23 CET Richmond wrote:
nicholas wrote:
The system would not boot. :)
I can't remember exactly what happened. I could try and re-create it on another computer if you are really interested.
. please do, i would wager there is something wrong with your setup or the grub sequence is very non-intuitive. the most i would expect is trouble with conficts on non restored drives (opt/home).
Well, in this thread you can see another person with that problem: Subject: [opensuse-factory] Snapper: cannot boot from any snapshots You have participated there. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
On Sunday, 26 February 2017 19:49:42 CET Carlos E. R. wrote:
On 2017-02-26 19:25, nicholas wrote:
On Sunday, 26 February 2017 19:14:23 CET Richmond wrote:
nicholas wrote:
The system would not boot. :)
I can't remember exactly what happened. I could try and re-create it on another computer if you are really interested.
.
please do, i would wager there is something wrong with your setup or the grub sequence is very non-intuitive. the most i would expect is trouble with conficts on non restored drives (opt/home).
Well, in this thread you can see another person with that problem:
Subject: [opensuse-factory] Snapper: cannot boot from any snapshots
You have participated there.
and the outcome was: 1) all initial attempts failed due to non-intuitive grub interface 2) we dont know reason for later failed attempt, but it did not fail to start booting. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
nicholas wrote:
nicholas wrote:
On Sunday, 26 February 2017 18:20:59 CET Richmond wrote:
Snapshots were useful for retrieving the occasional file, but I never succeeded in booting from a snapshot. Always they were unbootable. i find it hard to believe that this was a technical failure on multiple occasions, can you describe what you mean by unbootable? The system would not boot. :)
I can't remember exactly what happened. I could try and re-create it on another computer if you are really interested.
.
On Sunday, 26 February 2017 19:14:23 CET Richmond wrote: please do, i would wager there is something wrong with your setup or the grub sequence is very non-intuitive. the most i would expect is trouble with conficts on non restored drives (opt/home).
I booted up the other computer and found that it has 40G so it wouldn't be a good test. I was able to boot from a snapshot too, the grub menu seemed straight forward. I could shrink the btrfs file system and try it. But I don't know if gparted supports btrfs. Anyway if the consensus is that 20G is too small, I shan't bother. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 28/02/2017 à 12:41, Richmond a écrit :
gparted supports btrfs. Anyway if the consensus is that 20G is too small, I shan't bother.
too small only to use snapshots, but then btrfs may not be the better choice jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-02-26 19:00, nicholas wrote:
On Sunday, 26 February 2017 18:20:59 CET Richmond wrote:
Snapshots were useful for retrieving the occasional file, but I never succeeded in booting from a snapshot. Always they were unbootable.
i find it hard to believe that this was a technical failure on multiple occasions, can you describe what you mean by unbootable?
It simply does not work at that size. I think the current default is to disable them. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))
participants (20)
-
Aaron Digulla -
Andrei Borzenkov -
Anthony Youngman -
Anton Aylward -
ArnoB -
Carlos E. R. -
Dr.-Ing. Dieter Jurzitza -
Fraser_Bell -
jdd -
John Andersen -
Karl Sinn -
L A Walsh -
Lew Wolfgang -
Mikhail Kasimov -
nicholas -
Patrick Shanahan -
Richard Brown -
Richmond -
suse＠a-domani.nl -
Wols Lists