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 2017-02-26 12:38, Richard Brown wrote:

On 26 February 2017 at 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.

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 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 :-)

:-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" (Minas Tirith))

26.02.2017 14:38, Richard Brown пишет:

On 26 February 2017 at 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.

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

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))

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))

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))

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))

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))

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 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

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

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

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 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

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

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

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

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 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

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 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 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 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 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

* ArnoB [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

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 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 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

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 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 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 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 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 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))

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 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 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 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 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

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 26 February 2017 at 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.

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 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

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/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 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))

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))

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

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:

...

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

26.02.2017 21:53, nicholas пишет:

20 gb wouldnt work due to the way space is allocated.

What are you talking about? -- 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))

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

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

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

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 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))

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 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

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