btrfs says no errors, but booting gives lots of errors

btrfs says no errors, but booting gives lots of errors

[covici]

[-- Attachment #1: Type: text/plain, Size: 3018 bytes --]

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.

[-- Attachment #2: rdsosreport.zip --]
[-- Type: application/zip, Size: 24662 bytes --]

[-- Attachment #3: Type: text/plain, Size: 150 bytes --]


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: btrfs says no errors, but booting gives lots of errors

[Holger Hoffstätte]

On 10/10/15 14:46, covici@ccs.covici.com 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

Re: btrfs says no errors, but booting gives lots of errors

[covici]

Holger Hoffstätte <holger.hoffstaette@googlemail.com> wrote:

> On 10/10/15 14:46, covici@ccs.covici.com 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.

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.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: btrfs says no errors, but booting gives lots of errors

[Lionel Bouton]

Le 10/10/2015 16:41, covici@ccs.covici.com a écrit :
> Holger Hoffstätte <holger.hoffstaette@googlemail.com> wrote:
>
>> On 10/10/15 14:46, covici@ccs.covici.com 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

Re: btrfs says no errors, but booting gives lots of errors

[Holger Hoffstätte]

On 10/10/15 17:46, Lionel Bouton wrote:
> Le 10/10/2015 16:41, covici@ccs.covici.com a écrit :
>> Holger Hoffstätte <holger.hoffstaette@googlemail.com> wrote:
>>
>>> On 10/10/15 14:46, covici@ccs.covici.com 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).

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

Re: btrfs says no errors, but booting gives lots of errors

[covici]

Holger Hoffstätte <holger.hoffstaette@googlemail.com> wrote:

> On 10/10/15 17:46, Lionel Bouton wrote:
> > Le 10/10/2015 16:41, covici@ccs.covici.com a écrit :
> >> Holger Hoffstätte <holger.hoffstaette@googlemail.com> wrote:
> >>
> >>> On 10/10/15 14:46, covici@ccs.covici.com 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).
> 
> 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.


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: btrfs says no errors, but booting gives lots of errors

[Lionel Bouton]

Le 10/10/2015 18:55, covici@ccs.covici.com 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

Re: btrfs says no errors, but booting gives lots of errors

[covici]

Lionel Bouton <lionel+ceph@bouton.name> wrote:

> Le 10/10/2015 18:55, covici@ccs.covici.com 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.

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?

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: btrfs says no errors, but booting gives lots of errors

[covici]

covici@ccs.covici.com wrote:

> Lionel Bouton <lionel+ceph@bouton.name> wrote:
> 
> > Le 10/10/2015 18:55, covici@ccs.covici.com 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.
> 
> 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?

I do have 4.2.2, I could go to, would that be better?

Re: btrfs says no errors, but booting gives lots of errors

[Duncan]

covici posted on Sat, 10 Oct 2015 19:08:16 -0400 as excerpted:

> covici@ccs.covici.com wrote:
> 
>> Lionel Bouton <lionel+ceph@bouton.name> wrote:
>> 
>> > Le 10/10/2015 18:55, covici@ccs.covici.com 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.
> 
> 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.

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

Re: btrfs says no errors, but booting gives lots of errors

[covici]

Duncan <1i5t5.duncan@cox.net> wrote:

> covici posted on Sat, 10 Oct 2015 19:08:16 -0400 as excerpted:
> 
> > covici@ccs.covici.com wrote:
> > 
> >> Lionel Bouton <lionel+ceph@bouton.name> wrote:
> >> 
> >> > Le 10/10/2015 18:55, covici@ccs.covici.com 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.
> > 
> > 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.

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.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: btrfs says no errors, but booting gives lots of errors

[Duncan]

covici posted on Sun, 11 Oct 2015 08:29:27 -0400 as excerpted:

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

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

Re: btrfs says no errors, but booting gives lots of errors

[Lionel Bouton]

Le 11/10/2015 01:02, covici@ccs.covici.com a écrit :
> Lionel Bouton <lionel+ceph@bouton.name> wrote:
>
>> Le 10/10/2015 18:55, covici@ccs.covici.com 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.
> 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.

If you can list files and read them, your problems probably have nothing
to do with the filesystem itself.

Lionel

Re: btrfs says no errors, but booting gives lots of errors

[covici]

Lionel Bouton <lionel-subscription@bouton.name> wrote:

> Le 11/10/2015 01:02, covici@ccs.covici.com a écrit :
> > Lionel Bouton <lionel+ceph@bouton.name> wrote:
> >
> >> Le 10/10/2015 18:55, covici@ccs.covici.com 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.
> > 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.
> 
> 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.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: btrfs says no errors, but booting gives lots of errors

[Lionel Bouton]

Le 11/10/2015 01:32, covici@ccs.covici.com 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

Re: btrfs says no errors, but booting gives lots of errors

[covici]

Lionel Bouton <lionel-subscription@bouton.name> wrote:

> Le 11/10/2015 01:32, covici@ccs.covici.com 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.

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.


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: btrfs says no errors, but booting gives lots of errors

[covici]

Lionel Bouton <lionel-subscription@bouton.name> wrote:

> Le 10/10/2015 16:41, covici@ccs.covici.com a écrit :
> > Holger Hoffstätte <holger.hoffstaette@googlemail.com> wrote:
> >
> >> On 10/10/15 14:46, covici@ccs.covici.com 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).

I do use those patches.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com