On 04/02/2015 10:58 AM, John Andersen wrote:

On 4/2/2015 2:19 AM, Bernhard Voelker wrote:

...

On 04/02/2015 05:51 AM, John M Andersen wrote:

...

Couple weeks ago I went on vacation. In preparation, I backed up laptop, and shut it down, (powered off).

Today, I get back, fire it up, and the root file system (btrfs) will only mount in read-only mode.

I don't use BTRFS, so here's a hint in another direction:

Can you rule out a disc/hardware issue?

Have a nice day, Berny

Smart shows the drive to be perfect, (it is essentially new), its never had any tracks remapped, or any indication of failure or pre-failure.

There are, as I've mentioned, been several panics based on watchdog timer detecting that one processor had a hard locked up. Turns out when you look into that, the problem is common, and has been patched, but apparently that has not been fixed on OpenSuse. I never get these panics on a 3.16.6-2. (Came on the DVD) I frequently get the panic on 3.16.7-7.

Google this phrase: "Kernel panic - not syncing: Watchdog detected hard" It has a lot of hits in a lot of different distros.

I'm prepared to accept the fact that the panic has corrupted the BTRFS file system but since BTRFS has no tools to repair a corruption I'm going to have to re-install, because it won't run long enough to perform any kind of restore.

Its been an interesting experiment, but if any little thing goes wrong, you are toast with btrfs. I've had (on other hardware) panics on other file systems and never lost any data. If we designed buildings this fragile, the first damn woodpecker to come along would destroy civilization.

(This is opensuse 13.2 from a fresh install).

John, I posted in another thread that I was able to backup my btrfs file system to a USB drive, take that drive to another identical system, load the system there and boot it. So backups are possible with btrfs. I just run on a laptops (rather big ones) so have not been impressed with the requirements for the snapshots, and have them disabled them on my systems. In another entry I was described as "Joe Sixpack Linux users that are dazed by these new concepts". But I now have backups, and have not had other problems with btrfs. There seems to be a desire to always reinvent the wheel, KISS is dead:-) I can give more details on how I do my backup if desired. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/06/2015 10:14 AM, jdd wrote:

Le 06/04/2015 19:11, don fisher a écrit :

...

I can give more details on how I do my backup if desired.

I could take it, thanks!

jdd

My initial goal was to be able to have two identical systems. During the course of operation, numerous packages were added or updated which did not made a system reinstall appear a simple, valid option. I had helpful emails from many members of the list, but I will not include their names to avoid their incrimination. First I installed an openSuse 13.2 system on my 500GB USB drive. I figured that installing openSuse would establish the btrfs, the correct /boot entries for that drive, along with the correct volume IDs in fstab. These entries are exclude form overwrite in the attached excludes file. I then mounted the USB / and /home partitions, on my system at /mnt/usr11 and /mnt/usr12. These are the first two entries in the attached script, commented out because for now, I do them by hand. I then did an rsync from primary / to / on the USB drive, and from primary /home to the /home on the USB drive. The two rsync commands in the included file are different because I desired an exact copy, and rsync normally pays attention to file creation dates. But if the openSuse system on the USB drive was created after the one on my primary system, files there could have later dates and not be updated. Therefore I used the -c switch to rsync telling it to match checksums (on the rsync command target for the root directory). I let rsync in the /home partition match dates to avoid needless computation of checksums. I have also attached my excludes file. There may be more probably in /var, that could be excluded. But so far this works. When the system boots I assumed that it would overwrite any files present that it does not require. My background is as an EE, spent most of my time in image processing, real time applications and assembler code. So please forgive any glaring errors in formats. Never took a computer science course:-( Suggestions for improvements would be appreciated. (Also, the dot at the start of my excludes file name is missing, Thunderbird would not show the . files to allow their attachment :-) Don

On 04/06/2015 02:10 PM, jdd wrote:

Le 06/04/2015 20:45, don fisher a écrit :

...

My initial goal was to be able to have two identical systems. During the course of operation, numerous packages were added or updated which did not made a system reinstall appear a simple, valid option.

it's valid, but not simple :-(

Just a detail, I got the feeling that your backup drive was bootable in p)lace of the old one, is this true? or is it necessary to restore the system in case of failure?

because in the latter case there are solution using less volume on disk (like using the rpm database to rebuild the distribution and only backup the config folders.

I also have some questions about database and web applications, but I guess you don't have a web server on this computer :-).

I would like to have only to copy the /etc folder to keep the config, but part of it is not in this folder, some being in the database (in /var), some other in htdocs, some other who knows where :-).

also I think you had questions about btrfs subvolumes, I didn't read an answer

thanks jdd

I made my USB drive bootable. If the machine died I wanted to be able to boot the USB drive and restore the system. Tell me more about the RPM database. I assumed the existence of, but did not search out, a place where a record of all of the packages existing on my system were stored. Please tell me were it is. USB drive are almost free now, so I didn't care about the space it required to make my backup. I do not recall the questions about btrfs subvolumes. It was pointed out to me that there were two ways of looking at the volume, via / and via the subvolums. btrfs puts the data in the correct subvolumes if the data is written to root. So I basically ignore the subvolumes. As far as I can tell there purpose is to isolate sections of the filesystem so that snapshots will work, but I have them disabled anyway. Don -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/06/2015 02:45 PM, don fisher wrote:

...

My initial goal was to be able to have two identical systems. During the course of operation, numerous packages were added or updated which did not made a system reinstall appear a simple, valid option.

I've never done EXACTLY that, but what I have done is taken a listing of what's in the RPM database, the list of all the packages installed on a machine and their revisions, edited, and then used it, with a suitable script processing each line, to install "all" (well most) the packages on another machine. Rather than copy, I made the repositories do the hard work. Back then I had copious (employer supplied) bandwidth. At home, paying, I would install from CD and do another dump of the RPM database and diff to see what I would have to add and only process that. The RPM database is a wondrous thing and I find I peer into it for various purposes quite often. Today, for example, I looked to see what OTHER binaries/runables and external optional modules came with a package. -- 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 04/02/2015 07:12 PM, John Andersen wrote:

With BTRFS I was never sure how much room/free space I had available, how many snapshots I should keep, etc. I never understood why they chose to implement so many sub-directories of root as sub-volumes, when all those sub-volumes were drawing on the same free space pool!

I'm letting it mature and letting the tool set mature so that Joe User has a chance of understanding what is going on, or it gets to the state of Reiserfs where you just don't have to worry about it.

That is precisely what a filesystem should do/provide. It's just something that is there, that does it's job, that the user never revisits after creating it. (except for fsck....) Over the course of the past 16 - 17 years, I have lost many many disks, but never data due to a filesystem failure or error. I count at least a handful of BTRFS failures discussed on the list in the past 6 months or so. BTRFS may end up being the next best thing since sliced bread, but currently it seams the loaf is not quite yet done for production environments. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-04-03 04:15, David C. Rankin wrote:

Over the course of the past 16 - 17 years, I have lost many many disks, but never data due to a filesystem failure or error.

I had corrupted partitions with all filesystem types. Unrecoverable. ext3, reiserfs, xfs... You just have to hit on the wrong nail. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlUiap0ACgkQja8UbcUWM1wkFwEAkioqYuttWACpXXw/WQBg7RvH rH8aAyGPp9E0RvkHLfUA/ikguz8DbYcv+OZfh5nRgO8z6ulOJDTmJ8dGLvkDE0mH =608o -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 4/2/2015 8:10 PM, Anton Aylward wrote:

the programmers were damn god.

And at least one was damned by god, as well as the State of California. Ultimately, Reiser's problems were visited upon the software. And even though Opensuse was the principal maintainer, it never survived. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/03/2015 04:35 AM, Bob Williams wrote:

A subvolume differs from a directory in a number of ways. It behaves as a mountable filesystem in it's own right, and is ignored when a snapshot of its parent is made. Thus when you snapshot /, the subvolumes in /home, /opt, /srv, /tmp and various /var/* will be automatically left out of the snapshot.

If we take the scenario where instead of the sub-volumes we have mount points and mountable file systems -- a more 'traditional' (and understandable) approach -- then there is an iso-morphism here. The snapshot doesn't cover the file systems mounted because they are different file systems. "Res ipse loquitur" The only difference is that in the total BtrFS case its all the one physical space. Since, as I've commented before, BtrFS is conceived as being the who system, this all makes sense. Now I run BtrFS as the root FS, took away the sub-volumes mentioned and have them as mounted file systems. All this is done on a backdrop of LVM. I can snapshot any file system using LVM. If ReiserFS had a long term future I wouldn't even be considering BtrFS for other than SSD. As it is, I feel trapped into a future where I have to use BtrFS (to avoid the fixed inode idiocy that has existed ever since the V6/7 FS for UNIX of the 1970s) and all the complexity, and the problems that goes with complexity, of the grand Design outlook of BtrFS. The idiea of having separate volume management and file systems appeals to me. Heck, with LVM I can even use (or if you prefer, 'experiment') with other file systems (including BtrFS as a file system!). In effect LVM is a platform that does for filesystems what the virtualization tools do for operating systems. Integrating the volume management and the file system all into one, as with BtrFS, removes that flexibility. -- This message represents the official view of the voices in my head -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On April 4, 2015 1:45:04 PM PDT, "Sam M." wrote:

I've been using btrfs for "/" and "/home" for months with zero problems, aside from a kernel bug that showed up when I plugged in an external HD that froze my PC which has been patched. What's the advantage to using XFS for /home? I haven't touched XFS for years, but never had any problems with it. I thought XFS performance was bad on small files.

On Fri, Apr 3, 2015 at 5:16 AM, Anton Aylward wrote:

...

On 04/03/2015 04:35 AM, Bob Williams wrote:

...

A subvolume differs from a directory in a number of ways. It behaves as a mountable filesystem in it's own right, and is ignored when a snapshot of its parent is made. Thus when you snapshot /, the subvolumes in /home, /opt, /srv, /tmp and various /var/* will be automatically left out of the snapshot.

If we take the scenario where instead of the sub-volumes we have mount points and mountable file systems -- a more 'traditional' (and understandable) approach -- then there is an iso-morphism here. The snapshot doesn't cover the file systems mounted because they are different file systems. "Res ipse loquitur"

The only difference is that in the total BtrFS case its all the one physical space. Since, as I've commented before, BtrFS is conceived as being the who system, this all makes sense.

Now I run BtrFS as the root FS, took away the sub-volumes mentioned and have them as mounted file systems. All this is done on a backdrop of LVM. I can snapshot any file system using LVM.

If ReiserFS had a long term future I wouldn't even be considering BtrFS for other than SSD.

As it is, I feel trapped into a future where I have to use BtrFS (to avoid the fixed inode idiocy that has existed ever since the V6/7 FS for UNIX of the 1970s) and all the complexity, and the problems that goes with complexity, of the grand Design outlook of BtrFS.

The idiea of having separate volume management and file systems appeals to me.

Heck, with LVM I can even use (or if you prefer, 'experiment') with other file systems (including BtrFS as a file system!). In effect LVM is a platform that does for filesystems what the virtualization tools do for operating systems.

Integrating the volume management and the file system all into one, as with BtrFS, removes that flexibility.

-- This message represents the official view of the voices in my head -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

My home is a mix of small files an very huge ones, big virtual machine files, largish images etc. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thursday 02 April 2015 19:04:56 Anton Aylward wrote:

What you described happened to me a long time ago, many revisions age. You don't' say which version of the kernel you use, BtrFS + Tools. Its in constant revision and along the way there have been ... Diversions ... That have been less than satisfactory.

I suppose one might say that one should never turn off the machine :-) Certainly every problem I've ever had has involved turning the machine back on :-) What? Disk crash from head retraction? BTDT a couple of times :-(

When this happened to me it was on a /home partition. I've never had it happen on a ROOT partition. Not even at the time I was also running the BtrFS-ificated /home. I did speculate that the BtrFS driver was not re-entrant, but was told that is not so.

So, what benefit is there to BtrFS other than its new and shiny?

My interest in it was to avoid the fixed number of inodes situation with ext4. I'd been bitten by that to many times in the last century and this. I had been using ReiserFS and was happy with that but people keep telling me its unsupported and won't be around.

ZFS is getting to look viable and does what BtrFS claims, volume management, spindle management over and above the simple partition model. Its reputed to be one of the really good things that came out of SUN. I can believe that. Is it production ready for Linux yet? I can't speak to that.

Linda recommends XFS. It seems very fiddly to me.

In the long run I wouldn't give up on BtrFS. KDE4 was a true Open Source project in that it was a 'ship early and get feedback' project. The mistake was that the early version were treated as production not as development. It was released as part of the main system, replacing KDE3 completely, before it was ready. Yes, it forced users to try it out, push its limits and report bugs. Perhaps if it hadn't been forced on us its development would have been slower. Perhaps too there would have been less antagonism.

BtrFS seems to have gone the same way, forced on us, and without a lot of consideration about such matters as "whole disk" vs partition, an issue which is key to the design assumptions; without adequate explanation of 'snapper'; without adequate explanation of subvolumes. All of these are new concepts. The questions that Don Fisher has posed are indicative, I think, of how the Joe Sixpack Linux users are dazed by these new concepts. I'm not sure how to handle them so have them all disabled.

Linda recommends XFS. Personally I find it too fiddly.

And there's JFS out of Veritas and IBM. I don't know anything about that.

Interesting summary, makes a lot of sense. And repetition of Linda and her XFS makes it little psychodelic :) For me btrfs works quite good so far, except for USB 3.0 SSD drive, where it constantly loses free space cache, which in turn hangs the systemd for all the eternity on umount and I have to use hard poweroff. At first I was using clear_cache mount option as default, but couple of days ago gave up and reformatted everything to ext4. At least it does not have the same issues. On the other hand, I've set btrfs on encrypted /home despite yast not allowing that. Was not so hard actually, and works much much better then XFS. And XFS was a complete disaster. I believe they have some kind of delayed flush, or something like that. Unpacking of 500 MB tar.xz tarball with the sources and git repository inside finished suspiciously fast, but in couple of seconds the system freezes and is absolutely not responsible for next 3-4 minutes, even mouse does not move. Yes, btrfs maybe not so fast, but at least the system remains usable the whole time. That is the one thing I miss from good old SUSE 8-10 days, when the choice of the file system was not a question at all, ReiserFS ruled them all. -- Regards, Stas -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

With continual streaming of data to disks (similar to unpacking a big archive, but worse), I found that I needed to run the following in a system init script. # This clears cache related to the disk. Without this the cache grows and, it seems, bad # things happen... Don't know if 60 seconds between calls is best... while [ 1 ]; do echo 1 > /proc/sys/vm/drop_caches; sleep 60; done & Then things stay even. Even though the targets were XFS, IIRC the behavior was for all file systems. It is a kernel memory management thing. Seems continual data streaming to disk is not the typical usage scenario so things are not tuned that way. On Sun, Apr 5, 2015 at 4:54 PM, Anton Aylward wrote:

On 04/03/2015 11:32 AM, Stanislav Baiduzhyi wrote:

...

And XFS was a complete disaster. I believe they have some kind of delayed flush, or something like that. Unpacking of 500 MB tar.xz tarball with the sources and git repository inside finished suspiciously fast, but in couple of seconds the system freezes and is absolutely not responsible for next 3-4 minutes, even mouse does not move. Yes, btrfs maybe not so fast, but at least the system remains usable the whole time.

That is the one thing I miss from good old SUSE 8-10 days, when the choice of the file system was not a question at all, ReiserFS ruled them all.

No need to cc me, I subscribe to the list ;-)

I'm glad I'm not alone in my preference for ReiserFS :-)

Is there any way we can pressure the SUSE Powers-That-Be to be more aggressive about ReiserFS maintenance and its future or is everyone climbing about the Down Train to Hell that is BtrFS?

I've joined the BtrFS list and what I'm seeing bothers me a bit and makes me think, once again, what a wonderful work ReiserFS is.

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

-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 05/04/2015 17:43, Anton Aylward a écrit :

But just unpacking archives? That's bursty. Unpack, compile ...

untaring achives largers than the available ram always was a problem for me... don't know exactly why jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-04-05 17:43, Anton Aylward wrote:

But just unpacking archives? That's bursty. Unpack, compile ... Or are you doing something that is continuous unpacking and nothing else?

The kernel can cache the entire unpack operation in RAM, and do the actual writing to disk later. XFS also uses RAM structures more than other filesystems. That delayed, intensive, write operation can tax heavily some computers more than normal. It happens to some people, that complain that even the mouse doesn't respond. Running a kernel build on a reiserfs partition runs faster than on ext3, by the way. Lots of small files are created. XFS has dynamic inodes: the number is not fixed at filesystem creation time. The btrfs people take ideas from XFS, they have some developers in common, IIRC. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlUiciAACgkQja8UbcUWM1xrJwD/dICCfLZlEdo7vPpTOTx/CmuM luZkOZoMVK+3nDlkBWAA/R1hWBSVqgIsrPOzHMm7wcoa9r10OMhfNLwQHuMHr+fH =CEv4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/05/2015 11:33 AM, toothpik wrote:

...

I'm glad I'm not alone in my preference for ReiserFS :-)

...

Is there any way we can pressure the SUSE Powers-That-Be to be more aggressive about ReiserFS maintenance and its future or is everyone climbing about the Down Train to Hell that is BtrFS? I've joined the BtrFS list and what I'm seeing bothers me a bit and makes me think, once again, what a wonderful work ReiserFS is. is the only reason ReiserFS is being pushed aside is it's named after a supposedly bad person? I mean, what if we renamed it? If it were called LawAbidingCitizenFS or...

I also used to use ReiserFS and was annoyed when development stopped. I currently use ext4 on my systems. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 05/04/2015 17:33, toothpik a écrit :

is the only reason ReiserFS is being pushed aside is it's named after a supposedly bad person? I mean, what if we renamed it? If it were called LawAbidingCitizenFS or...

I guess Reiser was kind of mad, like many genius are, I think Reiserfs 4 was never acheived (and one use the V3?) so may be the code is unmanageable. What I know is that I was a great lover of reiserfs :-) first time I demonstrated it in my Linux User Group, one of the member walking unplugged accidentally my computer and it rebooted without problem. Ancient ext2 users will understand :-) that said BTRFS seems the future and may be it's best like this... jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/05/2015 08:53 AM, James Knott wrote:

On 04/05/2015 11:46 AM, jdd wrote:

...

first time I demonstrated it in my Linux User Group, one of the member walking unplugged accidentally my computer and it rebooted without problem. Ancient ext2 users will understand :-) Many years ago, I was on a course for the Datapoint 2200. It had an 8008 CPU in discrete logic, as the Intel microprocessor was too slow. It had 16 Kb of dynamic RAM and two cassette desks for storage. In the class, I "accidentally" tripped over the power cord for another guy's system, before he had a chance to save his code. ;-)

https://en.wikipedia.org/wiki/Datapoint_2200

That's really cool! Those were the daze I was using HP-2100 and PDP-8/S minicomputers with ASR-33 teletypes. I still have a 2100 manual in my Closet of Horrors, anyone interested? To keep this on-topic, I also miss ReiserFS, and wonder what it would take to jump-start development? Remember when Tatu closed ssh? How long did it take for openSSH to fork and take over? openReiser? In recent years I've been using XFS which easily supports huge files and filesystems, but I still have some boxes running ReiserFS. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/05/2015 11:33 AM, toothpik wrote:

is the only reason ReiserFS is being pushed aside is it's named after a supposedly bad person? I mean, what if we renamed it? If it were called LawAbidingCitizenFS or...

Its not as if he was the sole programmer. Namesys - his company - had a number of developers active on the file system development. http://en.wikipedia.org/wiki/ReiserFS#Move_away_from_ReiserFS_to_ext3 -- 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