btrfs says no errors, but booting gives lots of errors
Hi. I am having lots of btrfs troubles -- I am using a 4.1.9 kernel and the btrfs programs are 4.2. I did get one sort of a kernel oops which I will attach if the system lets me.
Now, let me tell you how this happened. I created the file system on this kernel, created a rootfs subvolume, a usr subvolume and var and home subvolume all at the top level.
Now, I then took my root file system, the usr file system and the var and home file systems, took the box offline, booted into a grml cd and did rsync of all that stuff into the new system, changed the fstab and rebooted. The boot partition is an ext4 partition, so that is not involved. I am using dracut and systemd and gentoo.
What I got was a mess, a lot of programs returned 203, such as mailman, postgresql, and others. I think programs could not find their files, even though I could do ls and see the names, for instance postgresql said it could not find its .conf, but it seemed there to me. After rebooting back to the old system, I did a scrub and found no errors.
So, what could be happening here, things appeared to mount correctly, I used the following fstab ----------
# /etc/fstab: static file system information.
#
# noatime turns off atimes for increased performance (atimes normally aren't # needed; notail increases performance of ReiserFS (at the expense of storage # efficiency). It's safe to drop the noatime options if you want and to # switch between notail / tail freely. # # The root filesystem should have a pass number of either 0 or 1. # All other filesystems should have a pass number of 0 or greater than 1. # # See the manpage fstab(5) for more information. #
# <fs> <mountpoint> <type> <opts> <dump/pass>
# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
#/dev/BOOT /boot ext2 noauto,noatime 1 2
LABEL=main / btrfs defaults,subvol=rootfs 0 1/dev/sda1 /boot ext4 defaults 0 1
LABEL=swap none swap sw 0 0
#/dev/fd0 /mnt/floppy auto noauto 0 0
# NOTE: The next line is critical for boot!
proc /proc proc defaults 0 0
# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for # POSIX shared memory (shm_open, shm_unlink). # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will # use almost no memory if not populated with files) shm /dev/shm tmpfs nodev,nosuid,noexec 0 0 LABEL=main /usr btrfs defaults,subvol=/usr 0 2 /dev/mapper/linux--files-usr--src /usr/src ext4 defaults 0 2 LABEL=main /tmp btrfs defaults,subvol=/tmp,nodev,nosuid,noexec 0 2 LABEL=main /var btrfs defaults,subvol=/var 0 3 LABEL=main /var/tmp/portage btrfs defaults,subvol=/portage 0 3 LABEL=main /home btrfs defaults,subvol=/home 0 3 /dev/mapper/linux--files-audio /audio ext4 defaults 0 3 /dev/mapper/linux--files-usr--bbs /usr/bbs ext4 defaults 0 3 /dev/mapper/linux--files-hard2 /hard2 ext4 defaults 0 3 /dev/cdrom /mnt/cdrom auto noauto,user 0 0 /dev/mapper/linux--files-scratch /mnt/scratch ext4 defaults 0 3
So, any ideas?
Thanks in advance for any suggestions.
Signature · 7 lines
--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici
[email protected]Quoted 1 line · On 10/10/15 14:46, [email protected] wrote:
Hi. I am having lots of btrfs troubles -- I am using a 4.1.9 kernel
Just FYI, both 4.1.9 and .10 have serious regressions in the network layer that *will* lock up the whole machine, either after a few minutes or a few hours (when idle). Try 4.2.x or (also more btrfs fixes) or 4.1.8 (OK).
However, as for your problem at hand:
[ 33.911258] ccs kernel: WARNING: CPU: 0 PID: 825 at fs/sync.c:55 sync_filesystem+0x26/0x95() [ 33.911773] ccs kernel: Modules linked in: hid_logitech_hidpp hid_logitech_dj usbhid ata_generic pata_acpi btrfs xor uas usb_storage raid6_pq crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd ehci_pci xhci_pci xhci_hcd ehci_hcd ahci libahci pata_marvell libata usbcore usb_common dm_mirror dm_region_hash dm_log dm_mod zfs(PO) zunicode(PO) zcommon(PO) znvpair(PO) spl(O) zavl(PO) ipv6 autofs4 [ 33.913500] ccs kernel: CPU: 0 PID: 825 Comm: mount Tainted: P O 4.1.9-gentoo-r1 #2 [ 33.914053] ccs kernel: Hardware name: Supermicro C7P67/C7P67, BIOS 4.6.4 07/01/2011 [ 33.914602] ccs kernel: 0000000000000009 ffff88007fabbbf8 ffffffff81457f11 0000000080000000 [ 33.915167] ccs kernel: 0000000000000000 ffff88007fabbc38 ffffffff81045b50 ffff880400000001 [ 33.915734] ccs kernel: ffffffff81168a98 ffff880425a0d800 ffff880425a0d800 0000000000000000 [ 33.916287] ccs kernel: Call Trace: [ 33.916823] ccs kernel: [<ffffffff81457f11>] dump_stack+0x4f/0x7b [ 33.917353] ccs kernel: [<ffffffff81045b50>] warn_slowpath_common+0xa1/0xbb [ 33.917876] ccs kernel: [<ffffffff81168a98>] ? sync_filesystem+0x26/0x95 [ 33.918386] ccs kernel: [<ffffffff81045c0d>] warn_slowpath_null+0x1a/0x1c [ 33.918897] ccs kernel: [<ffffffff81168a98>] sync_filesystem+0x26/0x95 [ 33.919408] ccs kernel: [<ffffffffa0649cd0>] btrfs_remount+0x88/0x412 [btrfs]
It looks like the problem fixed here: https://lkml.org/lkml/2015/4/8/17
This also went into 4.2, though you should be able to patch it (and the rest of this 3-part series) into 4.1.x if you're comfortable with that.
hth,
Holger
Quoted 24 lines · Holger Hoffstätte
Quoted 1 line · On 10/10/15 14:46, [email protected] wrote:
Hi. I am having lots of btrfs troubles -- I am using a 4.1.9 kernel
Just FYI, both 4.1.9 and .10 have serious regressions in the network layer that *will* lock up the whole machine, either after a few minutes or a few hours (when idle). Try 4.2.x or (also more btrfs fixes) or 4.1.8 (OK).
However, as for your problem at hand:
[ 33.911258] ccs kernel: WARNING: CPU: 0 PID: 825 at fs/sync.c:55 sync_filesystem+0x26/0x95() [ 33.911773] ccs kernel: Modules linked in: hid_logitech_hidpp hid_logitech_dj usbhid ata_generic pata_acpi btrfs xor uas usb_storage raid6_pq crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd ehci_pci xhci_pci xhci_hcd ehci_hcd ahci libahci pata_marvell libata usbcore usb_common dm_mirror dm_region_hash dm_log dm_mod zfs(PO) zunicode(PO) zcommon(PO) znvpair(PO) spl(O) zavl(PO) ipv6 autofs4 [ 33.913500] ccs kernel: CPU: 0 PID: 825 Comm: mount Tainted: P O 4.1.9-gentoo-r1 #2 [ 33.914053] ccs kernel: Hardware name: Supermicro C7P67/C7P67, BIOS 4.6.4 07/01/2011 [ 33.914602] ccs kernel: 0000000000000009 ffff88007fabbbf8 ffffffff81457f11 0000000080000000 [ 33.915167] ccs kernel: 0000000000000000 ffff88007fabbc38 ffffffff81045b50 ffff880400000001 [ 33.915734] ccs kernel: ffffffff81168a98 ffff880425a0d800 ffff880425a0d800 0000000000000000 [ 33.916287] ccs kernel: Call Trace: [ 33.916823] ccs kernel: [<ffffffff81457f11>] dump_stack+0x4f/0x7b [ 33.917353] ccs kernel: [<ffffffff81045b50>] warn_slowpath_common+0xa1/0xbb [ 33.917876] ccs kernel: [<ffffffff81168a98>] ? sync_filesystem+0x26/0x95 [ 33.918386] ccs kernel: [<ffffffff81045c0d>] warn_slowpath_null+0x1a/0x1c [ 33.918897] ccs kernel: [<ffffffff81168a98>] sync_filesystem+0x26/0x95 [ 33.919408] ccs kernel: [<ffffffffa0649cd0>] btrfs_remount+0x88/0x412 [btrfs]
Quoted 4 lines
It looks like the problem fixed here: https://lkml.org/lkml/2015/4/8/17
This also went into 4.2, though you should be able to patch it (and the rest of this 3-part series) into 4.1.x if you're comfortable with that.
Thanks, maybe I will try the 4.2, but what about the strange things that are going on, are they all caused by that kernel error?
Also, I could not run 4.2 at all when I tried it the other day, it would boot up, but after about a minute it went completely bonkers, so I backed off to the 4.1.9 as it may be supported somewhat long term -- there is a .10 already.
Signature · 6 lines
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici
[email protected]Quoted 7 lines · Le 10/10/2015 16:41, [email protected] a écrit :
Quoted 5 lines · Holger Hoffstätte
Quoted 1 line · On 10/10/15 14:46, [email protected] wrote:
Hi. I am having lots of btrfs troubles -- I am using a 4.1.9 kernel
Just FYI, both 4.1.9 and .10 have serious regressions in the network layer that *will* lock up the whole machine, either after a few minutes or a few hours (when idle). Try 4.2.x or (also more btrfs fixes) or 4.1.8 (OK).
If I'm not mistaken as the OP uses Gentoo gentoo-sources-4.1.9-r1 should have distribution patches for this (4.1 is LTS, not 4.2 so you might want to prefer the 4.1 series).
Lionel
Quoted 4 lines · Lionel Bouton
Quoted 3 lines · Le 10/10/2015 16:41, [email protected] a écrit :
Quoted 1 line · Holger Hoffstätte
On 10/10/15 14:46, [email protected] wrote:
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Hi. I am having lots of btrfs troubles -- I am using a 4.1.9 kernel
Just FYI, both 4.1.9 and .10 have serious regressions in the network layer that *will* lock up the whole machine, either after a few minutes or a few hours (when idle). Try 4.2.x or (also more btrfs fixes) or 4.1.8 (OK).
If I'm not mistaken as the OP uses Gentoo gentoo-sources-4.1.9-r1 should have distribution patches for this (4.1 is LTS, not 4.2 so you might want to prefer the 4.1 series).
Good point..after all I was the one who sent Mike a warning about that. :) Just saw that he had masked vanilla-.9/10, didn't see that he also added the required patch to gentoo-.9/10, since I use my own patches anyway.
-h
Quoted 4 lines · Lionel Bouton
Quoted 3 lines · Le 10/10/2015 16:41, [email protected] a écrit :
Quoted 1 line · Holger Hoffstätte
On 10/10/15 14:46, [email protected] wrote:
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Hi. I am having lots of btrfs troubles -- I am using a 4.1.9 kernel
Just FYI, both 4.1.9 and .10 have serious regressions in the network layer that *will* lock up the whole machine, either after a few minutes or a few hours (when idle). Try 4.2.x or (also more btrfs fixes) or 4.1.8 (OK).
If I'm not mistaken as the OP uses Gentoo gentoo-sources-4.1.9-r1 should have distribution patches for this (4.1 is LTS, not 4.2 so you might want to prefer the 4.1 series).
I do use those patches.
Signature · 6 lines
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici
[email protected]Quoted 10 lines · Holger Hoffstätte
Quoted 9 lines · Lionel Bouton
Quoted 7 lines · Le 10/10/2015 16:41, [email protected] a écrit :
Quoted 5 lines · Holger Hoffstätte
Quoted 1 line · On 10/10/15 14:46, [email protected] wrote:
Hi. I am having lots of btrfs troubles -- I am using a 4.1.9 kernel
Just FYI, both 4.1.9 and .10 have serious regressions in the network layer that *will* lock up the whole machine, either after a few minutes or a few hours (when idle). Try 4.2.x or (also more btrfs fixes) or 4.1.8 (OK).
Quoted 7 lines
Quoted 3 lines
If I'm not mistaken as the OP uses Gentoo gentoo-sources-4.1.9-r1 should have distribution patches for this (4.1 is LTS, not 4.2 so you might want to prefer the 4.1 series).
Good point..after all I was the one who sent Mike a warning about that. :) Just saw that he had masked vanilla-.9/10, didn't see that he also added the required patch to gentoo-.9/10, since I use my own patches anyway.
But do you folks have any idea about my original question, this leads me to think that btrfs is too new or something.
Signature · 6 lines
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici
[email protected]Quoted 3 lines · Le 10/10/2015 18:55, [email protected] a écrit :
[...]
But do you folks have any idea about my original question, this leads me to think that btrfs is too new or something.
I've seen a recent report of a problem with btrfs-progs 4.2 confirmed as a bug in mkfs. As you created the filesystem with it, it could be the problem.
Note that btrfs-progs 4.2 is marked ~amd64 on Gentoo: when you live on the bleeding edge you shouldn't be surprised to bleed sometimes ;-)
You might have more luck by better describing the errors. Your title mentions lots of errors, but there's only one log extract in a zip file for a filesystem being mounted and it's only a warning about lock contention which from an educated guess seems unlikely to make programs crash.
I'm not familiar with the 203 exit codes you mention. This seems a systemd thing with unclear meaning from a quick Google search so it isn't really helpful unless there are kernel oops or panics for these errors too.
Lionel
Quoted 11 lines · Lionel Bouton
Quoted 3 lines · Le 10/10/2015 18:55, [email protected] a écrit :
[...]
But do you folks have any idea about my original question, this leads me to think that btrfs is too new or something.I've seen a recent report of a problem with btrfs-progs 4.2 confirmed as a bug in mkfs. As you created the filesystem with it, it could be the problem.
Note that btrfs-progs 4.2 is marked ~amd64 on Gentoo: when you live on the bleeding edge you shouldn't be surprised to bleed sometimes ;-)
Quoted 9 lines
You might have more luck by better describing the errors. Your title mentions lots of errors, but there's only one log extract in a zip file for a filesystem being mounted and it's only a warning about lock contention which from an educated guess seems unlikely to make programs crash.
I'm not familiar with the 203 exit codes you mention. This seems a systemd thing with unclear meaning from a quick Google search so it isn't really helpful unless there are kernel oops or panics for these errors too.
These errors are not kernel panicks, they are just that systemd units are not starting and the programs that are executed in the unit files are returning these errors such as the 203 with no other explanation. I tried for instance to run /usr/bin/postgresql-9.4-check-db-dir and it said that postgresql.conf was missing, but I could do an ls on that file and got the name. I think I have more like that, but no kernel errors and scrub has no errors. Should I go back to an earlier btrfs progs and, if so, which one?
Signature · 6 lines
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici
[email protected]Quoted 23 lines · [email protected] wrote:
Quoted 11 lines · Lionel Bouton
Quoted 3 lines · Le 10/10/2015 18:55, [email protected] a écrit :
[...]
But do you folks have any idea about my original question, this leads me to think that btrfs is too new or something.I've seen a recent report of a problem with btrfs-progs 4.2 confirmed as a bug in mkfs. As you created the filesystem with it, it could be the problem.
Note that btrfs-progs 4.2 is marked ~amd64 on Gentoo: when you live on the bleeding edge you shouldn't be surprised to bleed sometimes ;-)Quoted 9 lines
You might have more luck by better describing the errors. Your title mentions lots of errors, but there's only one log extract in a zip file for a filesystem being mounted and it's only a warning about lock contention which from an educated guess seems unlikely to make programs crash.
I'm not familiar with the 203 exit codes you mention. This seems a systemd thing with unclear meaning from a quick Google search so it isn't really helpful unless there are kernel oops or panics for these errors too.
Quoted 8 lines
These errors are not kernel panicks, they are just that systemd units are not starting and the programs that are executed in the unit files are returning these errors such as the 203 with no other explanation. I tried for instance to run
/usr/bin/postgresql-9.4-check-db-dirand it said that postgresql.conf was missing, but I could do an ls on that file and got the name. I think I have more like that, but no kernel errors and scrub has no errors. Should I go back to an earlier btrfs progs and, if so, which one?
I do have 4.2.2, I could go to, would that be better?
Quoted 21 lines · Le 11/10/2015 01:02, [email protected] a écrit :
Quoted 10 lines · Lionel Bouton
Quoted 3 lines · Le 10/10/2015 18:55, [email protected] a écrit :
[...]
But do you folks have any idea about my original question, this leads me to think that btrfs is too new or something.I've seen a recent report of a problem with btrfs-progs 4.2 confirmed as a bug in mkfs. As you created the filesystem with it, it could be the problem.
Note that btrfs-progs 4.2 is marked ~amd64 on Gentoo: when you live on the bleeding edge you shouldn't be surprised to bleed sometimes ;-)Quoted 9 lines
You might have more luck by better describing the errors. Your title mentions lots of errors, but there's only one log extract in a zip file for a filesystem being mounted and it's only a warning about lock contention which from an educated guess seems unlikely to make programs crash.
I'm not familiar with the 203 exit codes you mention. This seems a systemd thing with unclear meaning from a quick Google search so it isn't really helpful unless there are kernel oops or panics for these errors too.
Quoted 6 lines
These errors are not kernel panicks, they are just that systemd units are not starting and the programs that are executed in the unit files are returning these errors such as the 203 with no other explanation. I tried for instance to run
/usr/bin/postgresql-9.4-check-db-dirand it said that postgresql.conf was missing, but I could do an ls on that file and got the name.
If you can list files and read them, your problems probably have nothing to do with the filesystem itself.
Lionel
Quoted 29 lines · Lionel Bouton
Quoted 21 lines · Le 11/10/2015 01:02, [email protected] a écrit :
Quoted 10 lines · Lionel Bouton
Quoted 3 lines · Le 10/10/2015 18:55, [email protected] a écrit :
[...]
But do you folks have any idea about my original question, this leads me to think that btrfs is too new or something.I've seen a recent report of a problem with btrfs-progs 4.2 confirmed as a bug in mkfs. As you created the filesystem with it, it could be the problem.
Note that btrfs-progs 4.2 is marked ~amd64 on Gentoo: when you live on the bleeding edge you shouldn't be surprised to bleed sometimes ;-)Quoted 9 lines
You might have more luck by better describing the errors. Your title mentions lots of errors, but there's only one log extract in a zip file for a filesystem being mounted and it's only a warning about lock contention which from an educated guess seems unlikely to make programs crash.
I'm not familiar with the 203 exit codes you mention. This seems a systemd thing with unclear meaning from a quick Google search so it isn't really helpful unless there are kernel oops or panics for these errors too.Quoted 6 lines
These errors are not kernel panicks, they are just that systemd units are not starting and the programs that are executed in the unit files are returning these errors such as the 203 with no other explanation. I tried for instance to run
/usr/bin/postgresql-9.4-check-db-dirand it said that postgresql.conf was missing, but I could do an ls on that file and got the name.
Quoted 2 lines
If you can list files and read them, your problems probably have nothing to do with the filesystem itself.
I don't know if the file in question had the correct data, I only did a directory listing, but this makes no sense -- I did an rsync just before booting and got all kinds of errors and the only difference is the file system, this is what I am saying.
Signature · 6 lines
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici
[email protected]Quoted 5 lines · Le 11/10/2015 01:32, [email protected] a écrit :
[...]
I don't know if the file in question had the correct data, I only did a directory listing, but this makes no sense -- I did an rsync just before booting and got all kinds of errors and the only difference is the file system, this is what I am saying.
What makes no sense is that the same filesystem both shows the file is there and isn't. If there was data corruption or buggy behaviour at least it should be somehow consistent.
What is more likely is that the rsync was incomplete and didn't transfer some data needed by systemd: did you transfer (from the top of my head) extended attributes, special files, device files ? By default rsync doesn't do that.
Lionel
Quoted 7 lines · Lionel Bouton
Quoted 5 lines · Le 11/10/2015 01:32, [email protected] a écrit :
[...]
I don't know if the file in question had the correct data, I only did a directory listing, but this makes no sense -- I did an rsync just before booting and got all kinds of errors and the only difference is the file system, this is what I am saying.
Quoted 7 lines
What makes no sense is that the same filesystem both shows the file is there and isn't. If there was data corruption or buggy behaviour at least it should be somehow consistent.
What is more likely is that the rsync was incomplete and didn't transfer some data needed by systemd: did you transfer (from the top of my head) extended attributes, special files, device files ? By default rsync doesn't do that.
The only thing I transferred that was unusual is hard links. Otherwise it was just
rsync --progress -avhH --numeric-ids followed by the various source directories root file system to a subvolume rootfs, /usr to a subvolume called usr, var to a subvolume called var and home to a subvolume called home. And what is more confusing, I did check the contents of postgresql.conf and they matched exactly, the one on my ext4 system and the one on the btrfs file system -- so I don't know why the check program gave that message. Also, another thing which was not consistent is that in my first boot mysql service did not start, but it did in subsequent boots. Now, I did not transfer anything under /var/run as its linked to /run, same for /var/lock as its linked to /run/lock. Device files, I did not transfer anythin specific, I would think udev would create those under /dev. In this case, I wish I were doing something dumb, it would not be fun, but at least I could proceed and I could run with the system.
Signature · 6 lines
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici
[email protected]covici posted on Sat, 10 Oct 2015 19:08:16 -0400 as excerpted:
Quoted 9 lines
Quoted 7 lines · [email protected] wrote:
Quoted 5 lines · Lionel Bouton
Quoted 3 lines · Le 10/10/2015 18:55, [email protected] a écrit :
[...]
But do you folks have any idea about my original question, this leads me to think that btrfs is too new or something.
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
I've seen a recent report of a problem with btrfs-progs 4.2 confirmed as a bug in mkfs. As you created the filesystem with it, it could be the problem.
I do have 4.2.2, I could go to, would that be better?
btrfs-progs-4.2.2 does indeed have the mkfs.btrfs fixes for the bug in question. You should be fine remaking the filesystem with it.
If you created the filesystem with the buggy mkfs.btrfs, AFAIK, current 4.2.2 btrfs check can detect the error, but can't fix it. Blowing away the filesystem and recreating is the only known fix at this time, and filesystems created with the buggy version are not safe and could blow up at any time, so it's best to be rid of them and onto something more stable as soon as possible.
I can't help with the subvolumes bit, however, because while I'm on gentoo/~amd64 here too, also with systemd...
I don't use subvolumes, as to me it's simply putting too many eggs in one filesystem basket. Instead, I prefer multiple separate btrfs filesystems, each on their own partitions. My / includes most of what packages install, including /usr and /var but not /var/log. It's 8 GiB in size, under half used. /home is separate, the repos tree (gentoo and overlays) along with ccache, binpackages, the kernel tree, etc, are together on a separate partition, /var/log is separate (and tiny, half a GiB), etc. I keep / mounted read-only by default, so have the parts of / var/lib that must be runtime-writable symlinked to subdirs of /home/var, with /home of course mounted writable, but other than that and some /var/ log/ subdirs, anything that's installed by a package is on /, a lesson I learned the hard way when I had to recover from backups where /, /usr and /var were from backups taken on different dates and thus not synchronized with what portage /thought/ was installed based on /var/db/ pkg.
Not saying that's best for you, but it's a solution that I've found works very well for me, and the relative small 8 GiB size of / makes it easy to have backup copies of it that I can boot, should my working / take a dump. But if it's all on the same filesystem, as it is with subvolumes, and that filesystem takes a dump... it's all gone at once! That's not something I want to happen, so I vastly prefer the independent filesystems, but with everything (but the limited exceptions mentioned above) the package manager deals with on the same one, so it all stays synced and is backed up as a single unit, which after all remains reasonably small, 8 GiB, less than half used.
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Quoted 46 lines · Duncan
covici posted on Sat, 10 Oct 2015 19:08:16 -0400 as excerpted:
Quoted 9 lines
Quoted 7 lines · [email protected] wrote:
Quoted 5 lines · Lionel Bouton
Quoted 3 lines · Le 10/10/2015 18:55, [email protected] a écrit :
[...]
But do you folks have any idea about my original question, this leads me to think that btrfs is too new or something.Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
I've seen a recent report of a problem with btrfs-progs 4.2 confirmed as a bug in mkfs. As you created the filesystem with it, it could be the problem.
I do have 4.2.2, I could go to, would that be better?
btrfs-progs-4.2.2 does indeed have the mkfs.btrfs fixes for the bug in question. You should be fine remaking the filesystem with it.
If you created the filesystem with the buggy mkfs.btrfs, AFAIK, current 4.2.2 btrfs check can detect the error, but can't fix it. Blowing away the filesystem and recreating is the only known fix at this time, and filesystems created with the buggy version are not safe and could blow up at any time, so it's best to be rid of them and onto something more stable as soon as possible.
I can't help with the subvolumes bit, however, because while I'm on gentoo/~amd64 here too, also with systemd...
I don't use subvolumes, as to me it's simply putting too many eggs in one filesystem basket. Instead, I prefer multiple separate btrfs filesystems, each on their own partitions. My / includes most of what packages install, including /usr and /var but not
/var/log. It's 8 GiB in size, under half used. /home is separate, the repos tree (gentoo and overlays) along with ccache, binpackages, the kernel tree, etc, are together on a separate partition,/var/logis separate (and tiny, half a GiB), etc. I keep / mounted read-only by default, so have the parts of / var/lib that must be runtime-writable symlinked to subdirs of/home/var, with /home of course mounted writable, but other than that and some/var/log/ subdirs, anything that's installed by a package is on /, a lesson I learned the hard way when I had to recover from backups where /, /usr and /var were from backups taken on different dates and thus not synchronized with what portage /thought/ was installed based on/var/db/pkg.
Quoted 10 lines
Not saying that's best for you, but it's a solution that I've found works very well for me, and the relative small 8 GiB size of / makes it easy to have backup copies of it that I can boot, should my working / take a dump. But if it's all on the same filesystem, as it is with subvolumes, and that filesystem takes a dump... it's all gone at once! That's not something I want to happen, so I vastly prefer the independent filesystems, but with everything (but the limited exceptions mentioned above) the package manager deals with on the same one, so it all stays synced and is backed up as a single unit, which after all remains reasonably small, 8 GiB, less than half used.
Thanks, in the ext4 world, I have lvm and lots of things using separate lvm's. I don't want to go back to partitions, if btrfs is that fragile, maybe I should waita while yet. Or, I could use lvm and put btrfs on top of that, but it seems strange to me.
Signature · 6 lines
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici
[email protected]covici posted on Sun, 11 Oct 2015 08:29:27 -0400 as excerpted:
Quoted 4 lines
Thanks, in the ext4 world, I have lvm and lots of things using separate lvm's. I don't want to go back to partitions, if btrfs is that fragile, maybe I should waita while yet. Or, I could use lvm and put btrfs on top of that, but it seems strange to me.
Taking the larger picture perspective, I'd suggest that while btrfs arguably isn't "that fragile" if you're willing to work with it, it most definitely is of a status I characterize as "stabilizing, but not yet fully stable or mature", and as such, isn't likely to be the best choice for people who just want "sufficiently stable that I don't have to mess with it or worry about it", particularly if they're also the type that prefer to run "enterprise stable" or "debian stable" grade distros, which are, to put it mildly, not known for the up-to-dateness of the versions of various packages they ship. If that's a description of your comfort zone, then there's a basic incompatibility between your comfort zone and btrfs' current state, and btrfs probably isn't the right choice for you at this point.
In which case, ext3/4, reiserfs (my old favorite, which I had very good experience with even with not so reliable hardware), xfs, or possibly zfs if you need the features and are willing to put the money into the hardware it requires for stability, are more mature and arguably appropriate choices.
I had in mind to say something about the big-picture like that in an earlier reply, but forgot...
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman