Re: Small fs

[Duncan]

Chris Murphy posted on Sun, 11 Sep 2016 21:03:04 -0600 as excerpted:

> The man page says:
> "The recommended size for the mixed mode is for filesystems less than
> 1GiB." But in this case recommended !=default which requires some mental
> gymnastics to rectify. If mixed-bg becomes obsolete upon enospc being no
> more likely with isolated block groups, then OK fine, but in the
> meantime...

On the bright side, the double-whammy of being under such tight 
filesystem size constraints, coupled with finding out you have less than 
half the space of the filesystem actually available due to default-mixed-
mode AND default dup-metadata (thus dup everything), gets eliminated, and 
barring problems with unbalanced chunk-sizes, you actually get to use 
most of capacity of the filesystem for actual files, instead of less than 
half of it.

=:^)

But I remain unconvinced that benefit outweighs the serious 
administrative headaches trying to run without mixed-mode on such small 
btrfs is likely to generate.  And what's worse, it's the same folks that 
are likely to have problems coping with either issue, but fixing the 
under-half-available-for-use (at the cost of filesystem resiliency) is a 
one-time thing, while the administrative issue of unbalanced chunks is 
likely to come back to bite them again and again.

But still, having people find they can fit only ~110 MiB in a 256 MiB 
btrfs, while with ext*, they can fit say 240 MiB in the same size 
filesystem, could be a bit more to try to explain to the technically 
under-literate, than the devs decided they were willing to deal with.  
Just saying it'd divided in chunks and another chunk won't fit is 
arguably easier than trying to explain why the filesystem will fit less 
than half of what the size of it suggests it should fit, IOW.

And I think that argument /was/ made, to some extent.  But the whole 
thing only came up because they found testing with small filesystems 
inconvenient due to the mixed-bg default, so rather than fix that by 
fixing the tests, they broke the previously sane defaults, instead.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: compress=lzo safe to use?

[Duncan]

Hans van Kranenburg posted on Sun, 11 Sep 2016 22:49:58 +0200 as
excerpted:

> So, you can use a lot of compress without problems for years.
> 
> Only if your hardware is starting to break in a specific way, causing
> lots and lots of checksum errors, the kernel might not be able to handle
> all of them at the same time currently.
> 
> The compress might be super stable itself, but in this case another part
> of the filesystem is not perfecty able to handle certain failure
> scenario's involving it.

Well put.

In my case I had problems trigger due to exactly two things, tho there 
are obviously other ways of triggering the same issues, including a crash 
in the middle of a commit, with one copy of the raid1 already updated 
while the other is still being written.:

1) I first discovered the problem when one of my pair of ssds was going 
bad.  Because I had btrfs raid1 and could normally scrub-fix things, and 
because I had backups anyway, I chose to continue running it for some 
time, just to see how it handled things, as more and more sectors became 
unwritable and were replaced by spares.  By the end I had several MiB 
worth of spares in-use, altho smart reported I had only used about 15% of 
the available spares, but by then it was getting bad enough and the 
newness had worn off, so I just replaced it and got rid of the hassle.

But as a result of the above, I had a *LOT* of practice with btrfs 
recovery, mostly running scrub.

And what I found was that if btrfs raid1 encounters too many checksum 
errors in compressed data it will crash btrfs and the kernel, even when 
it *SHOULD* recover from the other device because it has a good copy, as 
demonstrated by the fact that after a reboot, I could run a scrub and fix 
everything, no uncorrected errors at all.

At first I thought it was just the way btrfs worked -- that it could 
handle a few checksum errors but not too many at once.  I had no idea it 
was compression related.  But nobody else seemed to mention the problem, 
which I though a bit strange, until someone /did/ mention it, and 
furthermore, actually tested both compressed and uncompressed btrfs, and 
found the problem only when btrfs was reading compressed data.  If the 
data wasn't compressed, btrfs went ahead and read the second copy 
correctly, without crashing the system, every time.

The extra kink in this is that at the time, I had a boot-time service 
setup to cache (via cat > /dev/null) a bunch of files in a particular 
directory.  This particular directory is a cache for news archives, with 
articles on some groups going back over a decade to 2002, and my news 
client (pan) is slow to startup with several gigs of cached messages like 
that, so I had the boot-time service pre-cache everything, so by the time 
I started X and pan, it would be done or nearly so and I'd not have to 
wait for pan to startup.

The problem was that many of the new files were in this directory, and 
all that activity tended to hit the going-bad sectors on that ssd rather 
frequently, making one copy often bad.  Additionally, these are mostly 
text messages, so they compress quite well, meaning compress=lzo would 
trigger compression on many of them.

And because I had it reading them at boot, the kernel tended to overload 
on checksum errors before it finished booting, far more frequently than 
it would have otherwise.  Of course, that would crash the system before I 
could get a login in ordered to run btrfs scrub and fix the problem.

What I had to do then was boot to rescue mode, with the filesystems 
mounted but before normal services (including this caching service) ran, 
run the scrub from there, and then continue boot, which would then work 
just fine because I'd fixed all the checksum errors.

But, as I said I eventually got tired of the hassle and just replaced the 
failing device.  Btrfs replace worked nicely. =:^)

2a) My second trigger is that I've found that with multiple devices, as 
in multi-device btrfs, but also when I used to run mdraid, don't always 
resume from suspend-to-RAM very well.  Often one device takes longer to 
wake up than the other(s), and the kernel will try to resume while one 
still isn't responding properly.  (FWIW, I ran into this problem on 
spinning rust back on mdraid, but I see it now on ssds on btrfs as well, 
so it seems to be a common issue, which probably remains relatively 
obscure I'd guess because relatively few people with multi-device btrfs 
or mdraid do suspend-to-ram.)

The result is that btrfs will try to write to the remaining device(s), 
getting them out of sync with the one that isn't responding properly 
yet.  Ultimately this leads to a crash if I don't catch it and complete a 
controlled shutdown before that, and sometimes I see the same crash-on-
boot-due-to-too-many-checksum-errors problem I saw with #1.  I no longer 
have that caching job running at boot and thus don't see it as often, but 
it still happens occasionally.  Again, once I boot to 

Re: Small fs

[Duncan]

Imran Geriskovan posted on Sun, 11 Sep 2016 21:56:07 +0300 as excerpted:

> On 9/11/16, Duncan <1i5t5.dun...@cox.net> wrote:
>> Martin Steigerwald posted on Sun, 11 Sep 2016 17:32:44 +0200 as
>> excerpted:
 What is the smallest recommended fs size for btrfs?
 Can we say size should be in multiples of 64MB?
>>> Do you want to know the smalled *recommended* or the smallest
>>> *possible*
>>> size?
> 
> In fact both.
> I'm reconsidering my options for /boot

>> [Snip my detail points, leaving just the summary...]
 
>> So of my 256 MiB btrfs mixed-mode /boot, 31+4=35 MiB is overhead,
>> leaving 221 MiB for actual data and metadata.  But due to dup mode
>> that's halved, to 110.5 MiB usable space.
> 
> That's quite an info.. Thanks a lot..
> 
> Just to note again:
> Ordinary 127MB btrfs gives "Out of space" around 64MB payload. 128MB is
> usable to the end.

Thanks, and just to clarify for others possibly following along or 
googling it up later, that's single mode (as opposed to dup mode) for at 
least data, if in normal separate data/metadata mode, and single for the 
combined mixed-mode chunks if in mixed-bg mode, correct?

Because if the data is dup mode as well, as it would be by default in 
mixed-bg mode (unless on ssd), 128 MiB should allow storing only 64 MiB 
(and that's not accounting for the system chunk or global reserve 
metadata, so it'd be less than that) data.

> I'm experimenting with an extracted (and customized) initrd on /boot.
> That is, /boot is a "minimal root on its own" which can switch to real
> root or do other things. Kernel and modules at /boot will not support
> any fs other than btrfs. (Or it may)
> 
> It seems a minimally usable root around 10MB is possible.
> And it is free of udev and systemd..

You don't specifically mention the distro, but given that gentoo's one of 
the only general-purpose distros that hasn't switched to systemd yet (tho 
it offers the choice for those who want it, and I've taken that choice 
here), there's a fair chance that's what you're running, as both I and 
Martin Steigerwald (based on earlier threads) are.

FWIW, a bit more about my /boot (and kernel/initr*) layout, then, since 
it may be apropos... both because you're dealing with /boot, and because 
you might be on gentoo, as well, in which case you may find even more 
useful hints in the below.  Of course you can set it up how you like, but 
this is what I've found works very well for me. =:^)

1) Since I custom-configure and build my own kernels anyway, I build 
monolithic, no kernel modules, and indeed, the kernel options allowing 
loading modules are turned off -- more secure that way since I don't load 
modules anyway.

That simplifies a lot of stuff, including no longer needing module-init-
tools or whatever installed at all.  So it's not. (I negated the @system 
listing for it; actually I negated @system entirely and added what I 
actually needed to my @world via world-sets, but that's beside the point.)

2) Since a multi-device btrfs / effectively requires an initr*, I do run 
one, using dracut to generate it, but I don't boot it as a separate 
file.  Instead I have the kernel configured to pull it in and append it 
as an initramfs to each built kernel.

The idea here is that I keep tested-bootable kernels along with their 
tested-bootable initr*s around, so whatever I may be upgrading, kernel, 
dracut, the initr* itself, or some package with a binary in the initr*, I 
always have a fallback kernel and its attached initramfs that's tested 
bootable.  That way, should some kernel/initr* component fail, I know I 
can simply pick an older/tested kernel/initramfs file, since they're a 
single file, and boot with it, using that boot to investigate and fix the 
problem with the kernel/initramfs.  And I also know that once I've tested 
a kernel/initramfs to work, if it suddenly fails, it can't be something 
in the initramfs or kernel itself, as that is known to work, it must 
instead be some problem with the hardware or in the boot after handover 
to the main /.

One additional detail here regarding dracut:  Even if you've configured 
dracut to not worry about modules as you run a monolithic kernel, for 
some reason (bug?) it still requires (as opposed to uses if installed) 
rmmod for an initr* build.  Why it requires rmmod but not modprobe is 
beyond me, but it does.  So now I have a no-rmmod.patch in
/etc/portage/patches/sys-kernel/dracut , and I can use dracut setup for a 
monolithic kernel initr*, without having to have the useless rmmod from 
module-init-tools around for it to pull in when I build a new initr*.

3) Due to btrfs dup-mode halving my usable space on /boot, something I 
should have anticipated but didn't, I have only ~110 MiB of space on /
boot, and the grub2 installation eats up some of it.  Of course that 
leaves me way less room for kernels than I expected, particularly when I 
had the uncompressed initr* (that the kernel build compresses and appends 
as an initramfs 

Re: Small fs

[Chris Murphy]

On Sun, Sep 11, 2016 at 8:00 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Chris Murphy posted on Sun, 11 Sep 2016 14:33:18 -0600 as excerpted:
>
>> Something else that's screwy in that bug that I just realized, why is it
>> not defaulting to mixed-block groups on a 100MiB fallocated file? I
>> thought mixed-bg was the default below a certain size like 2GiB or
>> whatever?
>
> You apparently missed the memo...

I got the memo right after I clicked send and read the thread.

> Newer btrfs-progs mkfs.btrfs no longer defaults under-1-GiB to mixed-bg
> mode, tho it remains very strongly recommended below 1 GiB, and soft-
> recommended to somewhere between 4 and 32 GiB (I believe the wiki says 5
> GiB at this point but don't know how it arrived at that, but the numbers
> I've seen suggested on-list range between 4 and 32 GiB, as above).
>
> The explanation of why, based on the thread where I remember it coming
> up, was because defaulting to mixed-mode was making testing more
> complex.  Don't ask me to agree with that because I most certainly don't;
> IMO sane defaults for normal use, which everyone seems to agree mixed-
> mode for under a GiB is, should apply, and if testing needs special-
> cased, well, special-case it.  But none-the-less, that's the context in
> which it was agreed to do away with the mixed-mode default, despite it
> still being extremely strongly recommended for under a GiB.  

The man page says:
"The recommended size for the mixed mode is for filesystems less than
1GiB." But in this case recommended !=default which requires some
mental gymnastics to rectify. If mixed-bg becomes obsolete upon enospc
being no more likely with isolated block groups, then OK fine, but in
the meantime...


-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Small fs

[Duncan]

Chris Murphy posted on Sun, 11 Sep 2016 14:33:18 -0600 as excerpted:

> Something else that's screwy in that bug that I just realized, why is it
> not defaulting to mixed-block groups on a 100MiB fallocated file? I
> thought mixed-bg was the default below a certain size like 2GiB or
> whatever?

You apparently missed the memo...

Newer btrfs-progs mkfs.btrfs no longer defaults under-1-GiB to mixed-bg 
mode, tho it remains very strongly recommended below 1 GiB, and soft-
recommended to somewhere between 4 and 32 GiB (I believe the wiki says 5 
GiB at this point but don't know how it arrived at that, but the numbers 
I've seen suggested on-list range between 4 and 32 GiB, as above).

The explanation of why, based on the thread where I remember it coming 
up, was because defaulting to mixed-mode was making testing more 
complex.  Don't ask me to agree with that because I most certainly don't; 
IMO sane defaults for normal use, which everyone seems to agree mixed-
mode for under a GiB is, should apply, and if testing needs special-
cased, well, special-case it.  But none-the-less, that's the context in 
which it was agreed to do away with the mixed-mode default, despite it 
still being extremely strongly recommended for under a GiB.  

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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: compress=lzo safe to use?

[Steven Haigh]

On 2016-09-12 05:48, Martin Steigerwald wrote:

Am Sonntag, 26. Juni 2016, 13:13:04 CEST schrieb Steven Haigh:

On 26/06/16 12:30, Duncan wrote:
> Steven Haigh posted on Sun, 26 Jun 2016 02:39:23 +1000 as excerpted:
>> In every case, it was a flurry of csum error messages, then instant
>> death.
>
> This is very possibly a known bug in btrfs, that occurs even in raid1
> where a later scrub repairs all csum errors.  While in theory btrfs raid1
> should simply pull from the mirrored copy if its first try fails checksum
> (assuming the second one passes, of course), and it seems to do this just
> fine if there's only an occasional csum error, if it gets too many at
> once, it *does* unfortunately crash, despite the second copy being
> available and being just fine as later demonstrated by the scrub fixing
> the bad copy from the good one.
>
> I'm used to dealing with that here any time I have a bad shutdown (and
> I'm running live-git kde, which currently has a bug that triggers a
> system crash if I let it idle and shut off the monitors, so I've been
> getting crash shutdowns and having to deal with this unfortunately often,
> recently).  Fortunately I keep my root, with all system executables, etc,
> mounted read-only by default, so it's not affected and I can /almost/
> boot normally after such a crash.  The problem is /var/log and /home
> (which has some parts of /var that need to be writable symlinked into /
> home/var, so / can stay read-only).  Something in the normal after-crash
> boot triggers enough csum errors there that I often crash again.
>
> So I have to boot to emergency mode and manually mount the filesystems in
> question, so nothing's trying to access them until I run the scrub and
> fix the csum errors.  Scrub itself doesn't trigger the crash, thankfully,
> and once it has repaired all the csum errors due to partial writes on one
> mirror that either were never made or were properly completed on the
> other mirror, I can exit emergency mode and complete the normal boot (to
> the multi-user default target).  As there's no more csum errors then
> because scrub fixed them all, the boot doesn't crash due to too many such
> errors, and I'm back in business.
>
>
> Tho I believe at least the csum bug that affects me may only trigger if
> compression is (or perhaps has been in the past) enabled.  Since I run
> compress=lzo everywhere, that would certainly affect me.  It would also
> explain why the bug has remained around for quite some time as well,
> since presumably the devs don't run with compression on enough for this
> to have become a personal itch they needed to scratch, thus its remaining
> untraced and unfixed.
>
> So if you weren't using the compress option, your bug is probably
> different, but either way, the whole thing about too many csum errors at
> once triggering a system crash sure does sound familiar, here.

Yes, I was running the compress=lzo option as well... Maybe here lays 
a

common problem?


Hmm… I found this from being referred to by reading Debian wiki page on
BTRFS¹.

I use compress=lzo on BTRFS RAID 1 since April 2014 and I never found 
an

issue. Steven, your filesystem wasn´t RAID 1 but RAID 5 or 6?


Yes, I was using RAID6 - and it has had a track record of eating data. 
There's lots of problems with the implementation / correctness of 
RAID5/6 parity - which I'm pretty sure haven't been nailed down yet. The 
recommendation at the moment is just not to use RAID5 or RAID6 modes of 
BTRFS. The last I heard, if you were using RAID5/6 in BTRFS, the 
recommended action was to migrate your data to a different profile or a 
different FS.


I just want to assess whether using compress=lzo might be dangerous to 
use in
my setup. Actually right now I like to keep using it, since I think at 
least
one of the SSDs does not compress. And… well… /home and / where I use 
it are

both quite full already.


I don't believe the compress=lzo option by itself was a problem - but it 
*may* have an impact in the RAID5/6 parity problems? I'd be guessing 
here, but am happy to be corrected.


--
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] writeback: allow for dirty metadata accounting

[Dave Chinner]

On Fri, Sep 09, 2016 at 10:17:43AM +0200, Jan Kara wrote:
> On Mon 22-08-16 13:35:01, Josef Bacik wrote:
> > Provide a mechanism for file systems to indicate how much dirty metadata 
> > they
> > are holding.  This introduces a few things
> > 
> > 1) Zone stats for dirty metadata, which is the same as the NR_FILE_DIRTY.
> > 2) WB stat for dirty metadata.  This way we know if we need to try and call 
> > into
> > the file system to write out metadata.  This could potentially be used in 
> > the
> > future to make balancing of dirty pages smarter.
> 
> So I'm curious about one thing: In the previous posting you have mentioned
> that the main motivation for this work is to have a simple support for
> sub-pagesize dirty metadata blocks that need tracking in btrfs. However you
> do the dirty accounting at page granularity. What are your plans to handle
> this mismatch?
> 
> The thing is you actually shouldn't miscount by too much as that could
> upset some checks in mm checking how much dirty pages a node has directing
> how reclaim should be done... But it's a question whether NR_METADATA_DIRTY
> should be actually used in the checks in node_limits_ok() or in
> node_pagecache_reclaimable() at all because once you start accounting dirty
> slab objects, you are really on a thin ice...

The other thing I'm concerned about is that it's a btrfs-only thing,
which means having dirty btrfs metadata on a system with different
filesystems (e.g. btrfs root/home, XFS data) is going to affect how
memory balance and throttling is run on other filesystems. i.e. it's
going ot make a filesystem specific issue into a problem that
affects global behaviour.
> 
> > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> > index 56c8fda..d329f89 100644
> > --- a/fs/fs-writeback.c
> > +++ b/fs/fs-writeback.c
> > @@ -1809,6 +1809,7 @@ static unsigned long get_nr_dirty_pages(void)
> >  {
> > return global_node_page_state(NR_FILE_DIRTY) +
> > global_node_page_state(NR_UNSTABLE_NFS) +
> > +   global_node_page_state(NR_METADATA_DIRTY) +
> > get_nr_dirty_inodes();
> 
> With my question is also connected this - when we have NR_METADATA_DIRTY,
> we could just account dirty inodes there and get rid of this
> get_nr_dirty_inodes() hack...

Accounting of dirty inodes would have to applied to every
filesystem before that could be done, but

> But actually getting this to work right to be able to track dirty inodes would
> be useful on its own - some throlling of creation of dirty inodes would be
> useful for several filesystems (ext4, xfs, ...).

... this relies on the VFS being able to track and control all
dirtying of inodes and metadata.

Which, it should be noted, cannot be done unconditionally because
some filesystems /explicitly avoid/ dirtying VFS inodes for anything
other than dirty data and provide no mechanism to the VFS for
writeback inodes or their related metadata. e.g. XFS, where all
metadata changes are transactional and so all dirty inode tracking
and writeback control is internal the to the XFS transaction
subsystem.

Adding an external throttle to dirtying of metadata doesn't make any
sense in this sort of architecture - in XFS we already have all the
throttles and expedited writeback triggers integrated into the
transaction subsystem (e.g transaction reservation limits, log space
limits, periodic background writeback, memory reclaim triggers,
etc). It's all so tightly integrated around the physical structure
of the filesystem I can't see any way to sanely abstract it to work
with a generic "dirty list" accounting and writeback engine at this
point...

I can see how tracking of information such as the global amount of
dirty metadata is useful for diagnostics, but I'm not convinced we
should be using it for globally scoped external control of deeply
integrated and highly specific internal filesystem functionality.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: compress=lzo safe to use?

[Hans van Kranenburg]

On 09/11/2016 09:48 PM, Martin Steigerwald wrote:
> Am Sonntag, 26. Juni 2016, 13:13:04 CEST schrieb Steven Haigh:
>> On 26/06/16 12:30, Duncan wrote:
>>> Steven Haigh posted on Sun, 26 Jun 2016 02:39:23 +1000 as excerpted:
 In every case, it was a flurry of csum error messages, then instant
 death.
>>>
>>> This is very possibly a known bug in btrfs, that occurs even in raid1
>>> where a later scrub repairs all csum errors.  While in theory btrfs raid1
>>> should simply pull from the mirrored copy if its first try fails checksum
>>> (assuming the second one passes, of course), and it seems to do this just
>>> fine if there's only an occasional csum error, if it gets too many at
>>> once, it *does* unfortunately crash [...]

[...]

>>> different, but either way, the whole thing about too many csum errors at
>>> once triggering a system crash sure does sound familiar, here.
>>
>> Yes, I was running the compress=lzo option as well... Maybe here lays a
>> common problem?
> 
> Hmm… I found this from being referred to by reading Debian wiki page on 
> BTRFS¹.
> 
> I use compress=lzo on BTRFS RAID 1 since April 2014 and I never found an 
> issue. Steven, your filesystem wasn´t RAID 1 but RAID 5 or 6?

To quote you from the "stability a joke" thread (which I guess this
might be related to)... "For me so far even compress=lzo seems to be
stable, but well for others it may not."

So, you can use a lot of compress without problems for years.

Only if your hardware is starting to break in a specific way, causing
lots and lots of checksum errors, the kernel might not be able to handle
all of them at the same time currently.

The compress might be super stable itself, but in this case another part
of the filesystem is not perfecty able to handle certain failure
scenario's involving it.

Another way to find out about "are there issues with compression" is
looking in the kernel git history.

When searching for "compression" and "corruption", you'll find fixes
like these:

commit 0305cd5f7fca85dae392b9ba85b116896eb7c1c7
Author: Filipe Manana 
Date:   Fri Oct 16 12:34:25 2015 +0100

Btrfs: fix truncation of compressed and inlined extents

commit 808f80b46790f27e145c72112189d6a3be2bc884
Author: Filipe Manana 
Date:   Mon Sep 28 09:56:26 2015 +0100

Btrfs: update fix for read corruption of compressed and shared extents

commit 005efedf2c7d0a270ffbe28d8997b03844f3e3e7
Author: Filipe Manana 
Date:   Mon Sep 14 09:09:31 2015 +0100

Btrfs: fix read corruption of compressed and shared extents

commit 619d8c4ef7c5dd346add55da82c9179cd2e3387e
Author: Filipe Manana 
Date:   Sun May 3 01:56:00 2015 +0100

Btrfs: incremental send, fix clone operations for compressed extents

These commits fix actual data corruption issues. Still, it might be bugs
that you've never seen, even when using a kernel with these bugs for
years, because they require a certain "nasty sequence of events" to trigger.

But, when using compression you certainly want to have these commits in
the kernel you're running right now. And when the bugs caused
corruption, using a fixed kernel with not retroactively fix the corrupt
data.

Hint: "this was fixed in 4.x.y, so run that version or later" is not
always the only answer here, because you'll see that fixes like these
even show up in kernels like 3.16.y

But maybe I should continue by replying on the joke thread instead of
typing more here.

-- 
Hans van Kranenburg
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Small fs

[Chris Murphy]

On Sun, Sep 11, 2016 at 9:27 AM, Imran Geriskovan
 wrote:
> What is the smallest recommended fs size for btrfs?

It depends on the layout. And there is some confusion about the mkfs
command message it returns when it doesn't work out.

https://bugzilla.kernel.org/show_bug.cgi?id=112461

Something else that's screwy in that bug that I just realized, why is
it not defaulting to mixed-block groups on a 100MiB fallocated file? I
thought mixed-bg was the default below a certain size like 2GiB or
whatever?


>
> - There are mentions of 256MB around the net.
> - Gparted reserves minimum of 256MB for btrfs.
>
> With an ordinary partition on a single disk,
> fs created with just "mkfs.btrfs /dev/sdxx":
> - 128MB works fine.
> - 127MB works but as if it is 64MB.
>
> Can we say size should be in multiples of 64MB?

Why should it be in multiples?  I think what you're describing is part
of the bug above that just needs to be fixed. Btrfs itself internally
uses bytes, so multiples of 64MiB is OK but I wouldn't  use the word
"should" with it.

-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: compress=lzo safe to use? (was: Re: Trying to rescue my data :()

[Chris Murphy]

On Sun, Sep 11, 2016 at 2:06 PM, Adam Borowski  wrote:
> On Sun, Sep 11, 2016 at 09:48:35PM +0200, Martin Steigerwald wrote:
>> Hmm… I found this from being referred to by reading Debian wiki page on
>> BTRFS¹.
>>
>> I use compress=lzo on BTRFS RAID 1 since April 2014 and I never found an
>> issue. Steven, your filesystem wasn´t RAID 1 but RAID 5 or 6?
>>
>> I just want to assess whether using compress=lzo might be dangerous to use in
>> my setup. Actually right now I like to keep using it, since I think at least
>> one of the SSDs does not compress. And… well… /home and / where I use it are
>> both quite full already.
>>
>> [1] https://wiki.debian.org/Btrfs#WARNINGS
>
> I have used compress=lzo for years, kernels 3.8, 3.13 and 3.14 (a bunch of
> machines), without a single glitch; heavy snapshotting, single dev only, no
> quota.  Until recently I did never balanced.
>
> I did have a case of ENOSPC with <80% full on 4.7 which might or might not
> be related to compress=lzo.

I'm not finding it off hand, but Duncan has some experience with this
issue, where he'd occasionally have some sort of problem (hand wave),
I don't know how serious it was, maybe just scary warnings like a call
trace or something, but no actual problem? My recollection is that
compression might be making certain edge case problems more difficult
to recover from. I don't know why that would be, as metadata itself
isn't compressed (the inline data saved in metadata nodes can be
compressed). But there you go, if things start going wonky compression
might make it more difficult. But that's speculative. And I also don't
know if there's any difference between lzo and zlib in this regard
either.


-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is stability a joke?

[Chris Murphy]

On Sun, Sep 11, 2016 at 8:54 AM, Martin Steigerwald  wrote:
> Am Sonntag, 11. September 2016, 14:39:14 CEST schrieb Waxhead:
>> Martin Steigerwald wrote:
>> > Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin Steigerwald:
>> > The Nouveau graphics driver have a nice feature matrix on it's webpage
>> > and I think that BTRFS perhaps should consider doing something like
>> > that
>> > on it's official wiki as well
>> 
>>  BTRFS also has a feature matrix. The links to it are in the "News"
>>  section
>>  however:
>> 
>>  https://btrfs.wiki.kernel.org/index.php/Changelog#By_feature
> […]
>> > I mentioned this matrix as a good *starting* point. And I think it would
>> > be
>> > easy to extent it:
>> >
>> > Just add another column called "Production ready". Then research / ask
>> > about production stability of each feature. The only challenge is: Who is
>> > authoritative on that? I´d certainly ask the developer of a feature, but
>> > I´d also consider user reports to some extent.
>> >
>> > Maybe thats the real challenge.
>> >
>> > If you wish, I´d go through each feature there and give my own estimation.
>> > But I think there are others who are deeper into this.
>>
>> That is exactly the same reason I don't edit the wiki myself. I could of
>> course get it started and hopefully someone will correct what I write,
>> but I feel that if I start this off I don't have deep enough knowledge
>> to do a proper start. Perhaps I will change my mind about this.
>
> Well one thing would be to start with the column and start filling the more
> easy stuff. And if its not known since what kernel version, but its known to
> be stable I suggest to conservatively just put the first kernel version into
> it where people think it is stable or in doubt even put 4.7 into it. It can
> still be reduced to lower kernel versions.
>
> Well: I made a tiny start. I linked "Features by kernel version" more
> prominently on the main page, so it is easier to find and also added the
> following warning just above the table:
>
> "WARNING: The "Version" row states at which version a feature has been merged
> into the mainline kernel. It does not tell anything about at which kernel
> version it is considered mature enough for production use."
>
> Now I wonder: Would adding a "Production ready" column, stating the first
> known to be stable kernel version make sense in this table? What do you think?
> I can add the column and give some first rough, conservative estimations on a
> few features.
>
> What do you think? Is this a good place?

Yes. Again I'd emphasize keeping it simple, even at some risk of
oversimplification. There can be the "bird's eye view" matrix, with
some footnotes to further qualify things. And the rest of the wiki for
details that are often repeated on the list but shouldn't need to be
repeated on the list. And then the list for conversations/evaluations.
It is really a lot easier to make the wiki too verbose, making good
info harder to find. Wherever possible just take a stand, have an
opinion, defer explanations to links to posts. That way people who
want to read volumes of source material can, those who just need to
get on with business can too, rather than having to filter a volume of
stale material.

Production ready comes with some assumptions, like stable hardware. In
what ways is Btrfs less tolerant of device problems than other
configurations? In what was is Btrfs more tolerant? That might be a
good thread down the road.


-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is stability a joke?

[Chris Murphy]

On Sun, Sep 11, 2016 at 7:02 AM, Hugo Mills  wrote:
> On Sun, Sep 11, 2016 at 02:39:14PM +0200, Waxhead wrote:
>> Martin Steigerwald wrote:
>> >Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin Steigerwald:
>> Thing is: This just seems to be when has a feature been implemented
>> matrix.
>> Not when it is considered to be stable. I think this could be done with
>> colors or so. Like red for not supported, yellow for implemented and
>> green for production ready.
>> >>>Exactly, just like the Nouveau matrix. It clearly shows what you can
>> >>>expect from it.
>> >I mentioned this matrix as a good *starting* point. And I think it would be
>> >easy to extent it:
>> >
>> >Just add another column called "Production ready". Then research / ask about
>> >production stability of each feature. The only challenge is: Who is
>> >authoritative on that? I´d certainly ask the developer of a feature, but I´d
>> >also consider user reports to some extent.
>> >
>> >Maybe thats the real challenge.
>> >
>> >If you wish, I´d go through each feature there and give my own estimation. 
>> >But
>> >I think there are others who are deeper into this.
>> That is exactly the same reason I don't edit the wiki myself. I
>> could of course get it started and hopefully someone will correct
>> what I write, but I feel that if I start this off I don't have deep
>> enough knowledge to do a proper start. Perhaps I will change my mind
>> about this.
>
>Given that nobody else has done it yet, what are the odds that
> someone else will step up to do it now? I would say that you should at
> least try. Yes, you don't have as much knowledge as some others, but
> if you keep working at it, you'll gain that knowledge. Yes, you'll
> probably get it wrong to start with, but you probably won't get it
> *very* wrong. You'll probably get it horribly wrong at some point, but
> even the more knowledgable people you're deferring to didn't identify
> the problems with parity RAID until Zygo and Austin and Chris (and
> others) put in the work to pin down the exact issues.
>
>So I'd strongly encourage you to set up and maintain the stability
> matrix yourself -- you have the motivation at least, and the knowledge
> will come with time and effort. Just keep reading the mailing list and
> IRC and bugzilla, and try to identify where you see lots of repeated
> problems, and where bugfixes in those areas happen.
>
>So, go for it. You have a lot to offer the community.

I agree.

Mistakes happen, but there should be explanations. My suggestion is to
keep it really concise. It will be easier to maintain, less prone to
interpretation (better to get it flat out wrong, which gives it a
better chance of being caught and fixed, than being vague), and make
it more readable.

I recently received a beat down over on opensuse-factory list because
I said they should revert quotas by default. And the reason for that
was, hanging out here and connecting the only dots that are really
available upstream suggested they're ready for testing not production
usage. But suse/opensuse have a different opinion, and yet that
opinion hasn't been expressed on this list until recently. On the one
hand I'm a little annoyed the developer to user communication is
lacking significantly enough that this miscommunication can happen, on
the other hand I realize they're up to their eyeballs doing things
they do best which is fixing bugs and adding features. I don't know
that anyone has a perfect idea of what is "stable" until it passes the
test of time.

So you can expect things to change. Something might become clearly
less stable than we thought, more likely it'll become more stable than
it is now but in slow not so obvious ways.



-- 
Chris Murphy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: compress=lzo safe to use? (was: Re: Trying to rescue my data :()

[Adam Borowski]

On Sun, Sep 11, 2016 at 09:48:35PM +0200, Martin Steigerwald wrote:
> Hmm… I found this from being referred to by reading Debian wiki page on 
> BTRFS¹.
> 
> I use compress=lzo on BTRFS RAID 1 since April 2014 and I never found an 
> issue. Steven, your filesystem wasn´t RAID 1 but RAID 5 or 6?
> 
> I just want to assess whether using compress=lzo might be dangerous to use in 
> my setup. Actually right now I like to keep using it, since I think at least 
> one of the SSDs does not compress. And… well… /home and / where I use it are 
> both quite full already.
> 
> [1] https://wiki.debian.org/Btrfs#WARNINGS

I have used compress=lzo for years, kernels 3.8, 3.13 and 3.14 (a bunch of
machines), without a single glitch; heavy snapshotting, single dev only, no
quota.  Until recently I did never balanced.

I did have a case of ENOSPC with <80% full on 4.7 which might or might not
be related to compress=lzo.

-- 
Second "wet cat laying down on a powered-on box-less SoC on the desk" close
shave in a week.  Protect your ARMs, folks!
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Small fs

[Martin Steigerwald]

Am Sonntag, 11. September 2016, 19:46:32 CEST schrieb Hugo Mills:
> On Sun, Sep 11, 2016 at 09:13:28PM +0200, Martin Steigerwald wrote:
> > Am Sonntag, 11. September 2016, 16:44:23 CEST schrieb Duncan:
> > > * Metadata, and thus mixed-bg, defaults to DUP mode on a single-device
> > > filesystem (except on ssd where I actually still use it myself, and
> > > recommend it except for ssds that do firmware dedupe).  In mixed-mode
> > > this means two copies of data as well, which halves the usable space.
> > > 
> > > IOW, when using mixed-mode, which is recommended under a gig, and dup
> > > replication which is then the single-device default, effective usable
> > > space is **HALVED**, so 256 MiB btrfs size becomes 128 MiB usable. (!!)
> > 
> > I don´t get this part. That is just *metadata* being duplicated, not the
> > actual *data* inside the files. Or am I missing something here?
> 
>In mixed mode, there's no distinction: Data and metadata both use
> the same chunks. If those chunks are DUP, then both data and metadata
> are duplicated, and you get half the space available.

In german I´d say "autsch", in english according to pda.leo.org "ouch", to 
this.

Okay, I just erased using mixed mode as an idea from my mind altogether :).

Just like I think I will never use a BTRFS below 5 GiB. Well, with one 
exception, maybe on the eMMC flash of the new Omnia Turris router that I hope 
will arrive soon at my place.

-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

compress=lzo safe to use? (was: Re: Trying to rescue my data :()

[Martin Steigerwald]

Am Sonntag, 26. Juni 2016, 13:13:04 CEST schrieb Steven Haigh:
> On 26/06/16 12:30, Duncan wrote:
> > Steven Haigh posted on Sun, 26 Jun 2016 02:39:23 +1000 as excerpted:
> >> In every case, it was a flurry of csum error messages, then instant
> >> death.
> > 
> > This is very possibly a known bug in btrfs, that occurs even in raid1
> > where a later scrub repairs all csum errors.  While in theory btrfs raid1
> > should simply pull from the mirrored copy if its first try fails checksum
> > (assuming the second one passes, of course), and it seems to do this just
> > fine if there's only an occasional csum error, if it gets too many at
> > once, it *does* unfortunately crash, despite the second copy being
> > available and being just fine as later demonstrated by the scrub fixing
> > the bad copy from the good one.
> > 
> > I'm used to dealing with that here any time I have a bad shutdown (and
> > I'm running live-git kde, which currently has a bug that triggers a
> > system crash if I let it idle and shut off the monitors, so I've been
> > getting crash shutdowns and having to deal with this unfortunately often,
> > recently).  Fortunately I keep my root, with all system executables, etc,
> > mounted read-only by default, so it's not affected and I can /almost/
> > boot normally after such a crash.  The problem is /var/log and /home
> > (which has some parts of /var that need to be writable symlinked into /
> > home/var, so / can stay read-only).  Something in the normal after-crash
> > boot triggers enough csum errors there that I often crash again.
> > 
> > So I have to boot to emergency mode and manually mount the filesystems in
> > question, so nothing's trying to access them until I run the scrub and
> > fix the csum errors.  Scrub itself doesn't trigger the crash, thankfully,
> > and once it has repaired all the csum errors due to partial writes on one
> > mirror that either were never made or were properly completed on the
> > other mirror, I can exit emergency mode and complete the normal boot (to
> > the multi-user default target).  As there's no more csum errors then
> > because scrub fixed them all, the boot doesn't crash due to too many such
> > errors, and I'm back in business.
> > 
> > 
> > Tho I believe at least the csum bug that affects me may only trigger if
> > compression is (or perhaps has been in the past) enabled.  Since I run
> > compress=lzo everywhere, that would certainly affect me.  It would also
> > explain why the bug has remained around for quite some time as well,
> > since presumably the devs don't run with compression on enough for this
> > to have become a personal itch they needed to scratch, thus its remaining
> > untraced and unfixed.
> > 
> > So if you weren't using the compress option, your bug is probably
> > different, but either way, the whole thing about too many csum errors at
> > once triggering a system crash sure does sound familiar, here.
> 
> Yes, I was running the compress=lzo option as well... Maybe here lays a
> common problem?

Hmm… I found this from being referred to by reading Debian wiki page on 
BTRFS¹.

I use compress=lzo on BTRFS RAID 1 since April 2014 and I never found an 
issue. Steven, your filesystem wasn´t RAID 1 but RAID 5 or 6?

I just want to assess whether using compress=lzo might be dangerous to use in 
my setup. Actually right now I like to keep using it, since I think at least 
one of the SSDs does not compress. And… well… /home and / where I use it are 
both quite full already.

[1] https://wiki.debian.org/Btrfs#WARNINGS

Thanks,
-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Small fs

[Hugo Mills]

On Sun, Sep 11, 2016 at 09:13:28PM +0200, Martin Steigerwald wrote:
> Am Sonntag, 11. September 2016, 16:44:23 CEST schrieb Duncan:
> > * Metadata, and thus mixed-bg, defaults to DUP mode on a single-device 
> > filesystem (except on ssd where I actually still use it myself, and 
> > recommend it except for ssds that do firmware dedupe).  In mixed-mode 
> > this means two copies of data as well, which halves the usable space.
> > 
> > IOW, when using mixed-mode, which is recommended under a gig, and dup 
> > replication which is then the single-device default, effective usable 
> > space is **HALVED**, so 256 MiB btrfs size becomes 128 MiB usable. (!!)
> 
> I don´t get this part. That is just *metadata* being duplicated, not the 
> actual *data* inside the files. Or am I missing something here?

   In mixed mode, there's no distinction: Data and metadata both use
the same chunks. If those chunks are DUP, then both data and metadata
are duplicated, and you get half the space available.

   Hugo.

-- 
Hugo Mills | Questions are a burden, and answers a prison for
hugo@... carfax.org.uk | oneself
http://carfax.org.uk/  |
PGP: E2AB1DE4  |  The Prisoner


signature.asc
Description: Digital signature

Re: Small fs

[Martin Steigerwald]

Am Sonntag, 11. September 2016, 21:56:07 CEST schrieb Imran Geriskovan:
> On 9/11/16, Duncan <1i5t5.dun...@cox.net> wrote:
> > Martin Steigerwald posted on Sun, 11 Sep 2016 17:32:44 +0200 as excerpted:
> >>> What is the smallest recommended fs size for btrfs?
> >>> Can we say size should be in multiples of 64MB?
> >> 
> >> Do you want to know the smalled *recommended* or the smallest *possible*
> >> size?
> 
> In fact both.
> I'm reconsidering my options for /boot

Well my stance on boot still is: Ext4. Done.

:)

It just does not bother me. It practically makes no difference at all. It has 
no visible effect on my user experience and I never saw the need to snapshot /
boot.

But another approach in case you want to use BTRFS for /boot is to use a 
subvolume. Thats IMHO the SLES 12 default setup. They basically create 
subvolumes for /boot, /var, /var/lib/mysql – you name it. Big advantage: You 
have one big FS and do not need to plan space for partitions or LVs. 
Disadvantage: If it breaks, it breaks.

That said, I think at a new installation I may do this for /boot. Just put it 
inside a subvolume.

>From my experiences at work with customer systems and even some systems I 
setup myself, I often do not use little partitions anymore. I did so for a 
CentOS 7 training VM, just 2 GiB XFS for /var. Guess what happened? Last 
update was too long ago, so… yum tried to download a ton of packages and then 
complained it has not enough space in /var. Luckily I used LVM, so I enlarged 
partition LVM resides on, enlarged PV and then enlarged /var. There may be 
valid reasons to split things up, and I am quite comfortable with splitting /
boot out, cause its, well, plannable easily enough. And it may make sense to 
split /var or /var/log out. But on BTRFS I would likely use subvolumes. Only 
thing I may separate would be /home to make it easier on a re-installation of 
the OS to keep it around. That said, I never ever reinstalled the Debian on 
this ThinkPad T520 since I initially installed it. And on previous laptops I 
even copied the Debian on the older laptop onto the newer laptop. With the 
T520 I reinstalled, cause I wanted to switch to 64 bit cleanly.

-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Small fs

[Martin Steigerwald]

Am Sonntag, 11. September 2016, 16:44:23 CEST schrieb Duncan:
> * Metadata, and thus mixed-bg, defaults to DUP mode on a single-device 
> filesystem (except on ssd where I actually still use it myself, and 
> recommend it except for ssds that do firmware dedupe).  In mixed-mode 
> this means two copies of data as well, which halves the usable space.
> 
> IOW, when using mixed-mode, which is recommended under a gig, and dup 
> replication which is then the single-device default, effective usable 
> space is **HALVED**, so 256 MiB btrfs size becomes 128 MiB usable. (!!)

I don´t get this part. That is just *metadata* being duplicated, not the 
actual *data* inside the files. Or am I missing something here?

-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ioctl_xfs_ioc_getfsmap.2: document XFS_IOC_GETFSMAP ioctl

[Darrick J. Wong]

On Sat, Sep 10, 2016 at 10:00:29AM +1000, Dave Chinner wrote:
> On Thu, Sep 08, 2016 at 11:07:16PM -0700, Darrick J. Wong wrote:
> > On Fri, Sep 09, 2016 at 09:38:06AM +1000, Dave Chinner wrote:
> > > On Tue, Aug 30, 2016 at 12:09:49PM -0700, Darrick J. Wong wrote:
> > > > > I recall for FIEMAP that some filesystems may not have files aligned
> > > > > to sector offsets, and we just used byte offsets.  Storage like
> > > > > NVDIMMs are cacheline granular, so I don't think it makes sense to
> > > > > tie this to old disk sector sizes.  Alternately, the units could be
> > > > > in terms of fs blocks as returned by statvfs.st_bsize, but mixing
> > > > > units for fmv_block, fmv_offset, fmv_length is uneeded complexity.
> > > > 
> > > > Ugh.  I'd rather just change the units to bytes rather than force all
> > > > the users to multiply things. :)
> > > 
> > > Yup, units need to be either in disk addresses (i.e. 512 byte units)
> > > or bytes. If people can't handle disk addresses (seems to be the
> > > case), the bytes it should be.
> > 
> > 
> > 
> > > > I'd much rather just add more special owner codes for any other
> > > > filesystem that has distinguishable metadata types that are not
> > > > covered by the existing OWN_ codes.  We /do/ have 2^64 possible
> > > > values, so it's not like we're going to run out.
> > > 
> > > This is diagnositc information as much as anything, just like
> > > fiemap is diagnostic information. So if we have specific type
> > > information, it needs to be reported accurately to be useful.
> > > 
> > > Hence I really don't care if the users and developers of other fs
> > > types don't understand what the special owner codes that a specific
> > > filesystem returns mean. i.e. it's not useful user information -
> > > only a tool that groks the specific filesystem is going to be able
> > > to anything useful with special owner codes. So, IMO, there's little
> > > point trying to make them generic or to even trying to define and
> > > explain them in the man page
> > 
> >  I'm ok with describing generally what each special owner code
> > means.  Maybe the manpage could be more explicit about "None of these
> > codes are useful unless you're a low level filesystem tool"?
> 
> You can add that, but it doesn't address the underlying problem.
> i.e.  that we can add/change the codes, their name, meaning, etc,
> and now there's a third party man page that is incorrect and out of
> date. It's the same problem with documenting filesystem specific
> mount options in mount(8). Better, IMO, is to simple say "refer to
> filesystem specific documentation for a description of these special
> values". e.g. refer them to the XFS Filesystem Structure
> document where this is all spelled out in enough detail to be useful
> for someone thinking that they might want to use them

We could simply put a manpage in the xfsprogs source documenting the XFS
owner codes and let other implementers make their own manpage with a
discussion of the owner codes (and whatever other quirks they have).
Sort of fragments things, but that's probably unavoidable. :)

--D

> 
> Cheers,
> 
> Dave.
> -- 
> Dave Chinner
> da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Small fs

[Imran Geriskovan]

On 9/11/16, Duncan <1i5t5.dun...@cox.net> wrote:
> Martin Steigerwald posted on Sun, 11 Sep 2016 17:32:44 +0200 as excerpted:
>>> What is the smallest recommended fs size for btrfs?
>>> Can we say size should be in multiples of 64MB?
>> Do you want to know the smalled *recommended* or the smallest *possible*
>> size?

In fact both.
I'm reconsidering my options for /boot

> * Metadata, and thus mixed-bg, defaults to DUP mode on a single-device
> filesystem (except on ssd where I actually still use it myself, and
> recommend it except for ssds that do firmware dedupe).  In mixed-mode
> this means two copies of data as well, which halves the usable space.

> IOW, when using mixed-mode, which is recommended under a gig, and dup
> replication which is then the single-device default, effective usable
> space is **HALVED**, so 256 MiB btrfs size becomes 128 MiB usable. (!!)

> * There's also a system chunk to consider.  This too is normally dup mode
> on single device, raid1 on multi.  While it shrinks to some extent with
> size of filesystem, my 256 MiB /boot still has a 15.5 MiB system chunk,
> doubled due to dup mode to 31 MiB.  This is overhead you won't be able to
> use for anything else.
>
> * There's also global reserve.  This is a part of metadata (and thus
> mixed-mode) that cannot be used under normal circumstances either.
> However, unlike normal metadata, the accounting here is single -- it's X
> space reserved no matter the replication type.  On my 256 MiB /boot, it's
> 4 MiB.
>
> So of my 256 MiB btrfs mixed-mode /boot, 31+4=35 MiB is overhead, leaving
> 221 MiB for actual data and metadata.  But due to dup mode that's halved,
> to 110.5 MiB usable space.

That's quite an info.. Thanks a lot..

Just to note again:
Ordinary 127MB btrfs gives "Out of space" around
64MB payload. 128MB is usable to the end.

I'm experimenting with an extracted (and customized) initrd
on /boot. That is, /boot is a "minimal root on its own" which
can switch to real root or do other things. Kernel and modules
at /boot will not support any fs other than btrfs. (Or it may)

It seems a minimally usable root around 10MB is possible.
And it is free of udev and systemd..
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is stability a joke?

[Marc MERLIN]

On Sun, Sep 11, 2016 at 02:39:14PM +0200, Waxhead wrote:
> That is exactly the same reason I don't edit the wiki myself. I could of
> course get it started and hopefully someone will correct what I write, but I
> feel that if I start this off I don't have deep enough knowledge to do a
> proper start. Perhaps I will change my mind about this.

My first edits to the wiki was when I had barely started btrfs myself,
to simply write down answers to questions I had asked on the list and
that were not present on the wiki yet.

You don't have to be 100% right for everything, if something is wrong,
it'll likely bother someone and they'll go edit your changes, which is
more motivation and less work for them and write your changes from
scratch.
You can also add a small disclaimer "to the best of my knowledge",
etc...

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is stability a joke?

[Duncan]

Martin Steigerwald posted on Sun, 11 Sep 2016 14:05:03 +0200 as excerpted:

> Just add another column called "Production ready". Then research / ask
> about production stability of each feature. The only challenge is: Who
> is authoritative on that? I´d certainly ask the developer of a feature,
> but I´d also consider user reports to some extent.

Just a note that I'd *not* call it "production ready".  Btrfs in general 
is considered "stabilizing, not yet fully stable and mature", as I 
normally put it.  Thus, I'd call that column "stabilized to the level of 
btrfs in general", or perhaps just "stabilized", with a warning note with 
the longer form.

Because "production ready" can mean many things to many people.  The term 
seems to come from a big enterprise stack, with enterprise generally both 
somewhat conservative in deployment, and having backups and often hot-
spare-redundancy available, because lost time is lost money, and lost 
data has serious legal and financial implications.

But by the same token, /because/ they have the resources for fail-over, 
etc, large enterprises can and occasionally do deploy still stabilizing 
technologies, knowing they have fall-backs if needed, that smaller 
businesses and individuals often don't have.

Which is in my mind what's going on here.  Some places may be using it in 
production, but if they're sane, they have backups and even fail-over 
available.  Which is quite a bit different than saying it's "production 
ready" on an only machine, possibly with backups available but which 
would take some time to bring systems back up, and if it's a time is 
money environment, then...

Which again is far different than individual users, some of which 
unfortunately may not even have backups.

If "production ready" is taken to be the first group, with fail-overs 
available, etc, it means something entirely different than it does in the 
second and third cases, and I'd argue that while btrfs is ready for the 
first and can in some cases be ready for the second and the third if they 
have backups, it's definitely *not* "production ready" for the segment of 
the third that don't even have backups.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Small fs

[Duncan]

Martin Steigerwald posted on Sun, 11 Sep 2016 17:32:44 +0200 as excerpted:

> Am Sonntag, 11. September 2016, 18:27:30 CEST schrieben Sie:
>> What is the smallest recommended fs size for btrfs?
>> 
>> - There are mentions of 256MB around the net.
>> - Gparted reserves minimum of 256MB for btrfs.
>> 
>> With an ordinary partition on a single disk,
>> fs created with just "mkfs.btrfs /dev/sdxx":
>> - 128MB works fine.
>> - 127MB works but as if it is 64MB.
>> 
>> Can we say size should be in multiples of 64MB?
> 
> Do you want to know the smalled *recommended* or the smallest *possible*
> size?
> 
> I personally wouldn´t go below one or two GiB or or so with BTRFS. On
> small filesystems, I don´t know the treshold right now it uses a mixed
> metadata/data format. And I think using smaller BTRFS filesystem invited
> any left over "filesystem is full while it isn´t" issues.

I agree with the general recommendations and *strongly* recommend (and 
use) mixed-mode below say 2 GiB myself, but I don't necessarily agree 
that the practical bottom limit is 1 GiB, as I partition heavily and have 
a couple smaller btrfs myself.

There are some limits that should be kept in mind, however.

* Metadata, and thus mixed-bg, defaults to DUP mode on a single-device 
filesystem (except on ssd where I actually still use it myself, and 
recommend it except for ssds that do firmware dedupe).  In mixed-mode 
this means two copies of data as well, which halves the usable space.

IOW, when using mixed-mode, which is recommended under a gig, and dup 
replication which is then the single-device default, effective usable 
space is **HALVED**, so 256 MiB btrfs size becomes 128 MiB usable. (!!)

When the filesystem is that small, space tends to be at a premium in any 
case, and halving the available space can take a big bite out of things, 
so one considering such a btrfs should consider carefully, and possibly 
specify single mode if the loss of the data on the filesystem won't be a 
big deal, or double the filesystem size to account for dup data, if it 
would be more appropriate.

Or do pair-device which defaults to raid1 mode for metadata and mixed.  
Or choose a more traditional filesystem, perhaps ext* based, perhaps even 
without a journal if size is that constrained, because the journal takes 
space as well, because fscking that small a filesystem in the event of a 
crash shouldn't take that long anyway.

* There's also a system chunk to consider.  This too is normally dup mode 
on single device, raid1 on multi.  While it shrinks to some extent with 
size of filesystem, my 256 MiB /boot still has a 15.5 MiB system chunk, 
doubled due to dup mode to 31 MiB.  This is overhead you won't be able to 
use for anything else.

* There's also global reserve.  This is a part of metadata (and thus 
mixed-mode) that cannot be used under normal circumstances either.  
However, unlike normal metadata, the accounting here is single -- it's X 
space reserved no matter the replication type.  On my 256 MiB /boot, it's 
4 MiB.

So of my 256 MiB btrfs mixed-mode /boot, 31+4=35 MiB is overhead, leaving 
221 MiB for actual data and metadata.  But due to dup mode that's halved, 
to 110.5 MiB usable space.

For something like a dedicated /boot that may be acceptable.  For many 
applications it wouldn't be, and either the target size would need 
doubled, or filesystem robustness would need compromised by switching to 
single mode instead of dup.  Or use a different filesystem.

Tho to compare apples to apples, most other filesystems are only single 
mode anyway, and if it's an acceptable usage for them, it may well be an 
acceptable usage for btrfs as well.  It's just that btrfs likes a bit 
more metadata robustness than that.  But with such limited sizes, backing 
up the data if it's worth the hassle shouldn't be horribly time or 
resource consuming, and single mode can then make a bit more sense.

FWIW, in addition to my previously mentioned 256 MiB /boot, and a backup 
/boot (selectable via bios) on another device, I have a 640 MiB btrfs 
pair-device raid1 /var/log.  It's mixed-mode too, 640 MiB per device, but 
pair-device raid1, so I don't have to worry about the 2X data factor on a 
single device.

All my other "system" partitions are btrfs raid1 as well, including /, 
/home, and the packages/build partition.  But those are all over 2 GiB 
each.  All my btrfs are on ssd, with only my media partitions and backups 
on spinning rust (reiserfs).

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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Small fs

[Martin Steigerwald]

Am Sonntag, 11. September 2016, 18:27:30 CEST schrieben Sie:
> What is the smallest recommended fs size for btrfs?
> 
> - There are mentions of 256MB around the net.
> - Gparted reserves minimum of 256MB for btrfs.
> 
> With an ordinary partition on a single disk,
> fs created with just "mkfs.btrfs /dev/sdxx":
> - 128MB works fine.
> - 127MB works but as if it is 64MB.
> 
> Can we say size should be in multiples of 64MB?

Do you want to know the smalled *recommended* or the smallest *possible* size?

I personally wouldn´t go below one or two GiB or or so with BTRFS. On small 
filesystems, I don´t know the treshold right now it uses a mixed metadata/data 
format. And I think using smaller BTRFS filesystem invited any left over 
"filesystem is full while it isn´t" issues.

Well there we go. Excerpt from mkfs.btrfs(8) manpage:

   -M|--mixed
   Normally the data and metadata block groups are isolated.
   The mixed mode will remove the isolation and store both
   types in the same block group type. This helps to utilize
   the free space regardless of the purpose and is suitable
   for small devices. The separate allocation of block groups
   leads to a situation where the space is reserved for the
   other block group type, is not available for allocation and
   can lead to ENOSPC state.

   The recommended size for the mixed mode is for filesystems
   less than 1GiB. The soft recommendation is to use it for
   filesystems smaller than 5GiB. The mixed mode may lead to
   degraded performance on larger filesystems, but is
   otherwise usable, even on multiple devices.

   The nodesize and sectorsize must be equal, and the block
   group types must match.

   Note
   versions up to 4.2.x forced the mixed mode for devices
   smaller than 1GiB. This has been removed in 4.3+ as it
   caused some usability issues.

Thanks
-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Small fs

[Imran Geriskovan]

What is the smallest recommended fs size for btrfs?

- There are mentions of 256MB around the net.
- Gparted reserves minimum of 256MB for btrfs.

With an ordinary partition on a single disk,
fs created with just "mkfs.btrfs /dev/sdxx":
- 128MB works fine.
- 127MB works but as if it is 64MB.

Can we say size should be in multiples of 64MB?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is stability a joke?

[Martin Steigerwald]

Am Sonntag, 11. September 2016, 16:54:25 CEST schrieben Sie:
> Am Sonntag, 11. September 2016, 14:39:14 CEST schrieb Waxhead:
> > Martin Steigerwald wrote:
> > > Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin 
Steigerwald:
> > > The Nouveau graphics driver have a nice feature matrix on it's
> > > webpage
> > > and I think that BTRFS perhaps should consider doing something like
> > > that
> > > on it's official wiki as well
> >  
> >  BTRFS also has a feature matrix. The links to it are in the "News"
> >  section
> >  however:
> >  
> >  https://btrfs.wiki.kernel.org/index.php/Changelog#By_feature
> 
> […]
> 
> > > I mentioned this matrix as a good *starting* point. And I think it would
> > > be
> > > easy to extent it:
> > > 
> > > Just add another column called "Production ready". Then research / ask
> > > about production stability of each feature. The only challenge is: Who
> > > is
> > > authoritative on that? I´d certainly ask the developer of a feature, but
> > > I´d also consider user reports to some extent.
> > > 
> > > Maybe thats the real challenge.
> > > 
> > > If you wish, I´d go through each feature there and give my own
> > > estimation.
> > > But I think there are others who are deeper into this.
> > 
> > That is exactly the same reason I don't edit the wiki myself. I could of
> > course get it started and hopefully someone will correct what I write,
> > but I feel that if I start this off I don't have deep enough knowledge
> > to do a proper start. Perhaps I will change my mind about this.
> 
> Well one thing would be to start with the column and start filling the more
> easy stuff. And if its not known since what kernel version, but its known to
> be stable I suggest to conservatively just put the first kernel version
> into it where people think it is stable or in doubt even put 4.7 into it.
> It can still be reduced to lower kernel versions.
> 
> Well: I made a tiny start. I linked "Features by kernel version" more
> prominently on the main page, so it is easier to find and also added the
> following warning just above the table:
> 
> "WARNING: The "Version" row states at which version a feature has been
> merged into the mainline kernel. It does not tell anything about at which
> kernel version it is considered mature enough for production use."
> 
> Now I wonder: Would adding a "Production ready" column, stating the first
> known to be stable kernel version make sense in this table? What do you
> think? I can add the column and give some first rough, conservative
> estimations on a few features.
> 
> What do you think? Is this a good place?

It isn´t as straight forward to add this column as I thought. If I add it 
after "Version" then the following fields are not aligned anymore, even tough 
they use some kind of identifier – but that identifier also doesn´t match the 
row title. After reading about mediawiki syntax I came to the conclusion that 
I need to add the new column in every data row as well and cannot just assign 
values to the rows and leave out whats not known yet.

! Feature !! Version !! Description !! Notes
{{FeatureMerged
|name=scrub
|version=3.0
|text=Read all data and verify checksums, repair if possible.
}}

Thanks,
-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is stability a joke?

[Martin Steigerwald]

Am Sonntag, 11. September 2016, 13:02:21 CEST schrieb Hugo Mills:
> On Sun, Sep 11, 2016 at 02:39:14PM +0200, Waxhead wrote:
> > Martin Steigerwald wrote:
> > >Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin Steigerwald:
> > Thing is: This just seems to be when has a feature been implemented
> > matrix.
> > Not when it is considered to be stable. I think this could be done
> > with
> > colors or so. Like red for not supported, yellow for implemented and
> > green for production ready.
> > >>>
> > >>>Exactly, just like the Nouveau matrix. It clearly shows what you can
> > >>>expect from it.
> > >
> > >I mentioned this matrix as a good *starting* point. And I think it would
> > >be
> > >easy to extent it:
> > >
> > >Just add another column called "Production ready". Then research / ask
> > >about production stability of each feature. The only challenge is: Who
> > >is authoritative on that? I´d certainly ask the developer of a feature,
> > >but I´d also consider user reports to some extent.
> > >
> > >Maybe thats the real challenge.
> > >
> > >If you wish, I´d go through each feature there and give my own
> > >estimation. But I think there are others who are deeper into this.
> > 
> > That is exactly the same reason I don't edit the wiki myself. I
> > could of course get it started and hopefully someone will correct
> > what I write, but I feel that if I start this off I don't have deep
> > enough knowledge to do a proper start. Perhaps I will change my mind
> > about this.
> 
>Given that nobody else has done it yet, what are the odds that
> someone else will step up to do it now? I would say that you should at
> least try. Yes, you don't have as much knowledge as some others, but
> if you keep working at it, you'll gain that knowledge. Yes, you'll
> probably get it wrong to start with, but you probably won't get it
> *very* wrong. You'll probably get it horribly wrong at some point, but
> even the more knowledgable people you're deferring to didn't identify
> the problems with parity RAID until Zygo and Austin and Chris (and
> others) put in the work to pin down the exact issues.
> 
>So I'd strongly encourage you to set up and maintain the stability
> matrix yourself -- you have the motivation at least, and the knowledge
> will come with time and effort. Just keep reading the mailing list and
> IRC and bugzilla, and try to identify where you see lots of repeated
> problems, and where bugfixes in those areas happen.
> 
>So, go for it. You have a lot to offer the community.

Yep! Fully agreed.

-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is stability a joke?

[Martin Steigerwald]

Am Sonntag, 11. September 2016, 14:39:14 CEST schrieb Waxhead:
> Martin Steigerwald wrote:
> > Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin Steigerwald:
> > The Nouveau graphics driver have a nice feature matrix on it's webpage
> > and I think that BTRFS perhaps should consider doing something like
> > that
> > on it's official wiki as well
>  
>  BTRFS also has a feature matrix. The links to it are in the "News"
>  section
>  however:
>  
>  https://btrfs.wiki.kernel.org/index.php/Changelog#By_feature
[…]
> > I mentioned this matrix as a good *starting* point. And I think it would
> > be
> > easy to extent it:
> > 
> > Just add another column called "Production ready". Then research / ask
> > about production stability of each feature. The only challenge is: Who is
> > authoritative on that? I´d certainly ask the developer of a feature, but
> > I´d also consider user reports to some extent.
> > 
> > Maybe thats the real challenge.
> > 
> > If you wish, I´d go through each feature there and give my own estimation.
> > But I think there are others who are deeper into this.
> 
> That is exactly the same reason I don't edit the wiki myself. I could of
> course get it started and hopefully someone will correct what I write,
> but I feel that if I start this off I don't have deep enough knowledge
> to do a proper start. Perhaps I will change my mind about this.

Well one thing would be to start with the column and start filling the more 
easy stuff. And if its not known since what kernel version, but its known to 
be stable I suggest to conservatively just put the first kernel version into 
it where people think it is stable or in doubt even put 4.7 into it. It can 
still be reduced to lower kernel versions.

Well: I made a tiny start. I linked "Features by kernel version" more 
prominently on the main page, so it is easier to find and also added the 
following warning just above the table:

"WARNING: The "Version" row states at which version a feature has been merged 
into the mainline kernel. It does not tell anything about at which kernel 
version it is considered mature enough for production use."

Now I wonder: Would adding a "Production ready" column, stating the first 
known to be stable kernel version make sense in this table? What do you think? 
I can add the column and give some first rough, conservative estimations on a 
few features.

What do you think? Is this a good place?

Thanks,
-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is stability a joke?

[Martin Steigerwald]

Am Sonntag, 11. September 2016, 14:30:51 CEST schrieb Waxhead:
> > I think what would be a good next step would be to ask developers / users
> > about feature stability and then update the wiki. If thats important to
> > you, I suggest you invest some energy in doing that. And ask for help.
> > This mailinglist is a good idea.
> > 
> > I already gave you my idea on what works for me.
> > 
> > There is just one thing I won´t go further even a single step: The
> > complaining path. As it leads to no desirable outcome.
> > 
> > Thanks,
> 
> My intention was not to be hostile and if my response sound a bit harsh 
> for you then by all means I do apologize for that.

Okay, maybe I read something into your mail that you didn´t intend to put 
there. Sorry. Let us focus on the constructive way to move forward with this.

Thanks,
-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is stability a joke?

[Hugo Mills]

On Sun, Sep 11, 2016 at 02:39:14PM +0200, Waxhead wrote:
> Martin Steigerwald wrote:
> >Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin Steigerwald:
> Thing is: This just seems to be when has a feature been implemented
> matrix.
> Not when it is considered to be stable. I think this could be done with
> colors or so. Like red for not supported, yellow for implemented and
> green for production ready.
> >>>Exactly, just like the Nouveau matrix. It clearly shows what you can
> >>>expect from it.
> >I mentioned this matrix as a good *starting* point. And I think it would be
> >easy to extent it:
> >
> >Just add another column called "Production ready". Then research / ask about
> >production stability of each feature. The only challenge is: Who is
> >authoritative on that? I´d certainly ask the developer of a feature, but I´d
> >also consider user reports to some extent.
> >
> >Maybe thats the real challenge.
> >
> >If you wish, I´d go through each feature there and give my own estimation. 
> >But
> >I think there are others who are deeper into this.
> That is exactly the same reason I don't edit the wiki myself. I
> could of course get it started and hopefully someone will correct
> what I write, but I feel that if I start this off I don't have deep
> enough knowledge to do a proper start. Perhaps I will change my mind
> about this.

   Given that nobody else has done it yet, what are the odds that
someone else will step up to do it now? I would say that you should at
least try. Yes, you don't have as much knowledge as some others, but
if you keep working at it, you'll gain that knowledge. Yes, you'll
probably get it wrong to start with, but you probably won't get it
*very* wrong. You'll probably get it horribly wrong at some point, but
even the more knowledgable people you're deferring to didn't identify
the problems with parity RAID until Zygo and Austin and Chris (and
others) put in the work to pin down the exact issues.

   So I'd strongly encourage you to set up and maintain the stability
matrix yourself -- you have the motivation at least, and the knowledge
will come with time and effort. Just keep reading the mailing list and
IRC and bugzilla, and try to identify where you see lots of repeated
problems, and where bugfixes in those areas happen.

   So, go for it. You have a lot to offer the community.

   Hugo.

> >I do think for example that scrubbing and auto raid repair are stable, except
> >for RAID 5/6. Also device statistics and RAID 0 and 1 I consider to be 
> >stable.
> >I think RAID 10 is also stable, but as I do not run it, I don´t know. For me
> >also skinny-metadata is stable. For me so far even compress=lzo seems to be
> >stable, but well for others it may not.
> >
> >Since what kernel version? Now, there you go. I have no idea. All I know I
> >started BTRFS with Kernel 2.6.38 or 2.6.39 on my laptop, but not as RAID 1 at
> >that time.
> >
> >See, the implementation time of a feature is much easier to assess. Maybe
> >thats part of the reason why there is not stability matrix: Maybe no one
> >*exactly* knows *for sure*. How could you? So I would even put a footnote on
> >that "production ready" row explaining "Considered to be stable by developer
> >and user oppinions".
> >
> >Of course additionally it would be good to read about experiences of 
> >corporate
> >usage of BTRFS. I know at least Fujitsu, SUSE, Facebook, Oracle are using it.
> >But I don´t know in what configurations and with what experiences. One Oracle
> >developer invests a lot of time to bring BTRFS like features to XFS and 
> >RedHat
> >still favors XFS over BTRFS, even SLES defaults to XFS for /home and other 
> >non
> >/-filesystems. That also tells a story.
> >
> >Some ideas you can get from SUSE releasenotes. Even if you do not want to use
> >it, it tells something and I bet is one of the better sources of information
> >regarding your question you can get at this time. Cause I believe SUSE
> >developers invested some time to assess the stability of features. Cause they
> >would carefully assess what they can support in enterprise environments. 
> >There
> >is also someone from Fujitsu who shared experiences in a talk, I can search
> >the URL to the slides again.
> By all means, SUSE's wiki is very valuable. I just said that I
> *prefer* to have that stuff on the BTRFS wiki and feel that is the
> right place for it.
> >
> >I bet Chris Mason and other BTRFS developers at Facebook have some idea on
> >what they use within Facebook as well. To what extent they are allowed to 
> >talk
> >about it… I don´t know. My personal impression is that as soon as Chris went
> >to Facebook he became quite quiet. Maybe just due to being busy. Maybe due to
> >Facebook being concerned much more about the privacy of itself than of its
> >users.
> >
> >Thanks,
> 

-- 
Hugo Mills | How do you become King? You stand in the marketplace
hugo@... carfax.org.uk | and announce you're going to tax 

Re: Is stability a joke?

[Waxhead]

Martin Steigerwald wrote:

Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin Steigerwald:

The Nouveau graphics driver have a nice feature matrix on it's webpage
and I think that BTRFS perhaps should consider doing something like
that
on it's official wiki as well

BTRFS also has a feature matrix. The links to it are in the "News"
section
however:

https://btrfs.wiki.kernel.org/index.php/Changelog#By_feature

I disagree, this is not a feature / stability matrix. It is a clearly a
changelog by kernel version.

It is a *feature* matrix. I fully said its not about stability, but about
implementation – I just wrote this a sentence after this one. There is no
need  whatsoever to further discuss this as I never claimed that it is a
feature / stability matrix in the first place.


Thing is: This just seems to be when has a feature been implemented
matrix.
Not when it is considered to be stable. I think this could be done with
colors or so. Like red for not supported, yellow for implemented and
green for production ready.

Exactly, just like the Nouveau matrix. It clearly shows what you can
expect from it.

I mentioned this matrix as a good *starting* point. And I think it would be
easy to extent it:

Just add another column called "Production ready". Then research / ask about
production stability of each feature. The only challenge is: Who is
authoritative on that? I´d certainly ask the developer of a feature, but I´d
also consider user reports to some extent.

Maybe thats the real challenge.

If you wish, I´d go through each feature there and give my own estimation. But
I think there are others who are deeper into this.
That is exactly the same reason I don't edit the wiki myself. I could of 
course get it started and hopefully someone will correct what I write, 
but I feel that if I start this off I don't have deep enough knowledge 
to do a proper start. Perhaps I will change my mind about this.


I do think for example that scrubbing and auto raid repair are stable, except
for RAID 5/6. Also device statistics and RAID 0 and 1 I consider to be stable.
I think RAID 10 is also stable, but as I do not run it, I don´t know. For me
also skinny-metadata is stable. For me so far even compress=lzo seems to be
stable, but well for others it may not.

Since what kernel version? Now, there you go. I have no idea. All I know I
started BTRFS with Kernel 2.6.38 or 2.6.39 on my laptop, but not as RAID 1 at
that time.

See, the implementation time of a feature is much easier to assess. Maybe
thats part of the reason why there is not stability matrix: Maybe no one
*exactly* knows *for sure*. How could you? So I would even put a footnote on
that "production ready" row explaining "Considered to be stable by developer
and user oppinions".

Of course additionally it would be good to read about experiences of corporate
usage of BTRFS. I know at least Fujitsu, SUSE, Facebook, Oracle are using it.
But I don´t know in what configurations and with what experiences. One Oracle
developer invests a lot of time to bring BTRFS like features to XFS and RedHat
still favors XFS over BTRFS, even SLES defaults to XFS for /home and other non
/-filesystems. That also tells a story.

Some ideas you can get from SUSE releasenotes. Even if you do not want to use
it, it tells something and I bet is one of the better sources of information
regarding your question you can get at this time. Cause I believe SUSE
developers invested some time to assess the stability of features. Cause they
would carefully assess what they can support in enterprise environments. There
is also someone from Fujitsu who shared experiences in a talk, I can search
the URL to the slides again.
By all means, SUSE's wiki is very valuable. I just said that I *prefer* 
to have that stuff on the BTRFS wiki and feel that is the right place 
for it.


I bet Chris Mason and other BTRFS developers at Facebook have some idea on
what they use within Facebook as well. To what extent they are allowed to talk
about it… I don´t know. My personal impression is that as soon as Chris went
to Facebook he became quite quiet. Maybe just due to being busy. Maybe due to
Facebook being concerned much more about the privacy of itself than of its
users.

Thanks,


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is stability a joke?

[Waxhead]

Martin Steigerwald wrote:

Am Sonntag, 11. September 2016, 13:21:30 CEST schrieb Zoiled:

Martin Steigerwald wrote:

Am Sonntag, 11. September 2016, 10:55:21 CEST schrieb Waxhead:

I have been following BTRFS for years and have recently been starting to
use BTRFS more and more and as always BTRFS' stability is a hot topic.
Some says that BTRFS is a dead end research project while others claim
the opposite.

First off: On my systems BTRFS definately runs too stable for a research
project. Actually: I have zero issues with stability of BTRFS on *any* of
my systems at the moment and in the last half year.

The only issue I had till about half an year ago was BTRFS getting stuck
at
seeking free space on a highly fragmented RAID 1 + compress=lzo /home.
This
went away with either kernel 4.4 or 4.5.

Additionally I never ever lost even a single byte of data on my own BTRFS
filesystems. I had a checksum failure on one of the SSDs, but BTRFS RAID 1
repaired it.


Where do I use BTRFS?

1) On this ThinkPad T520 with two SSDs. /home and / in RAID 1, another
data
volume as single. In case you can read german, search blog.teamix.de for
BTRFS.

2) On my music box ThinkPad T42 for /home. I did not bother to change / so
far and may never to so for this laptop. It has a slow 2,5 inch harddisk.

3) I used it on Workstation at work as well for a data volume in RAID 1.
But workstation is no more (not due to a filesystem failure).

4) On a server VM for /home with Maildirs and Owncloud data. /var is still
on Ext4, but I want to migrate it as well. Whether I ever change /, I
don´t know.

5) On another server VM, a backup VM which I currently use with
borgbackup.
With borgbackup I actually wouldn´t really need BTRFS, but well…

6) On *all* of my externel eSATA based backup harddisks for snapshotting
older states of the backups.

In other words, you are one of those who claim the opposite :) I have
also myself run btrfs for a "toy" filesystem since 2013 without any
issues, but this is more or less irrelevant since some people have
experienced data loss thanks to unstable features that are not clearly
marked as such.
And making a claim that you have not lost a single byte of data does not
make sense, how did you test this? SHA256 against a backup? :)

Do you have any proof like that with *any* other filesystem on Linux?

No, my claim is a bit weaker: BTRFS own scrubbing feature and well no I/O
errors on rsyncing my data over to the backup drive - BTRFS checks checksum on
read as well –, and yes I know BTRFS uses a weaker hashing algorithm, I think
crc32c. Yet this is still more than what I can say about *any* other
filesystem I used so far. Up to my current knowledge neither XFS nor Ext4/3
provide data checksumming. They do have metadata checksumming and I found
contradicting information on whether XFS may support data checksumming in the
future, but up to now, no *proof* *whatsoever* from side of the filesystem
that the data is, what it was when I saved it initially. There may be bit
errors rotting on any of your Ext4 and XFS filesystem without you even
noticing for *years*. I think thats still unlikely, but it can happen, I have
seen this years ago after restoring a backup with bit errors from a hardware
RAID controller.

Of course, I rely on the checksumming feature within BTRFS – which may have
errors. But even that is more than with any other filesystem I had before.

And I do not scrub daily, especially not the backup disks, but for any scrubs
up to now, no issues. So, granted, my claim has been a bit bold. Right now I
have no up-to-this-day scrubs so all I can say is that I am not aware of any
data losses up to the point in time where I last scrubbed my devices. Just
redoing the scrubbing now on my laptop.
The way I see it BTRFS is the best filesystem we got so far. It is also 
the first (to my knowledge) that provides checksums of both data and 
metadata. My point was simply that such an extraordinary claim require 
some evidence. I am not saying it is unlikely that you have never lost a 
byte, I am just saying that it is a fantastic thing to claim.

The Debian wiki for BTRFS (which is recent by the way) contains a bunch
of warnings and recommendations and is for me a bit better than the
official BTRFS wiki when it comes to how to decide what features to use.

Nice page. I wasn´t aware of this one.

If you use BTRFS with Debian, I suggest to usually use the recent backport
kernel, currently 4.6.

Hmmm, maybe I better remove that compress=lzo mount option. Never saw any
issue with it, tough. Will research what they say about it.

My point exactly: You did not know about this and hence the risk of your
data being gnawed on.

Well I do follow BTRFS mailinglist to some extent and I recommend anyone who
uses BTRFS in production to do this. And: So far I see no data loss from using
that option and for me personally it is exactly that what counts. J

Still: An information on what features are stable with what version of kernel

Re: Is stability a joke?

[Zoiled]

Martin Steigerwald wrote:

Am Sonntag, 11. September 2016, 10:55:21 CEST schrieb Waxhead:

I have been following BTRFS for years and have recently been starting to
use BTRFS more and more and as always BTRFS' stability is a hot topic.
Some says that BTRFS is a dead end research project while others claim
the opposite.

First off: On my systems BTRFS definately runs too stable for a research
project. Actually: I have zero issues with stability of BTRFS on *any* of my
systems at the moment and in the last half year.

The only issue I had till about half an year ago was BTRFS getting stuck at
seeking free space on a highly fragmented RAID 1 + compress=lzo /home. This
went away with either kernel 4.4 or 4.5.

Additionally I never ever lost even a single byte of data on my own BTRFS
filesystems. I had a checksum failure on one of the SSDs, but BTRFS RAID 1
repaired it.


Where do I use BTRFS?

1) On this ThinkPad T520 with two SSDs. /home and / in RAID 1, another data
volume as single. In case you can read german, search blog.teamix.de for
BTRFS.

2) On my music box ThinkPad T42 for /home. I did not bother to change / so far
and may never to so for this laptop. It has a slow 2,5 inch harddisk.

3) I used it on Workstation at work as well for a data volume in RAID 1. But
workstation is no more (not due to a filesystem failure).

4) On a server VM for /home with Maildirs and Owncloud data. /var is still on
Ext4, but I want to migrate it as well. Whether I ever change /, I don´t know.

5) On another server VM, a backup VM which I currently use with borgbackup.
With borgbackup I actually wouldn´t really need BTRFS, but well…

6) On *all* of my externel eSATA based backup harddisks for snapshotting older
states of the backups.
In other words, you are one of those who claim the opposite :) I have 
also myself run btrfs for a "toy" filesystem since 2013 without any 
issues, but this is more or less irrelevant since some people have 
experienced data loss thanks to unstable features that are not clearly 
marked as such.
And making a claim that you have not lost a single byte of data does not 
make sense, how did you test this? SHA256 against a backup? :)

The Debian wiki for BTRFS (which is recent by the way) contains a bunch
of warnings and recommendations and is for me a bit better than the
official BTRFS wiki when it comes to how to decide what features to use.

Nice page. I wasn´t aware of this one.

If you use BTRFS with Debian, I suggest to usually use the recent backport
kernel, currently 4.6.

Hmmm, maybe I better remove that compress=lzo mount option. Never saw any
issue with it, tough. Will research what they say about it.
My point exactly: You did not know about this and hence the risk of your 
data being gnawed on.

The Nouveau graphics driver have a nice feature matrix on it's webpage
and I think that BTRFS perhaps should consider doing something like that
on it's official wiki as well

BTRFS also has a feature matrix. The links to it are in the "News" section
however:

https://btrfs.wiki.kernel.org/index.php/Changelog#By_feature
I disagree, this is not a feature / stability matrix. It is a clearly a 
changelog by kernel version.

Thing is: This just seems to be when has a feature been implemented matrix.
Not when it is considered to be stable. I think this could be done with colors
or so. Like red for not supported, yellow for implemented and green for
production ready.
Exactly, just like the Nouveau matrix. It clearly shows what you can 
expect from it.

Another hint you can get by reading SLES 12 releasenotes. SUSE dares to
support BTRFS since quite a while – frankly, I think for SLES 11 SP 3 this was
premature, at least for the initial release without updates, I have a VM that
with BTRFS I can break very easily having BTRFS say it is full, while it is
has still 2 GB free. But well… this still seems to happen for some people
according to the threads on BTRFS mailing list.

SUSE doesn´t support all of BTRFS. They even put features they do not support
behind a "allow_unsupported=1" module option:

https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-314697

But they even seem to contradict themselves by claiming they support RAID 0,
RAID 1 and RAID10, but not RAID 5 or RAID 6, but then putting RAID behind that
module option – or I misunderstood their RAID statement

"Btrfs is supported on top of MD (multiple devices) and DM (device mapper)
configurations. Use the YaST partitioner to achieve a proper setup.
Multivolume Btrfs is supported in RAID0, RAID1, and RAID10 profiles in SUSE
Linux Enterprise 12, higher RAID levels are not yet supported, but might be
enabled with a future service pack."

and they only support BTRFS on MD for RAID. They also do not support
compression yet. They even do not support big metadata.

https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-317221

Interestingly enough RedHat only supports BTRFS as a technology preview, even
with RHEL 7.

I would much rather 

Re: Is stability a joke?

[Martin Steigerwald]

Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin Steigerwald:
> > >> The Nouveau graphics driver have a nice feature matrix on it's webpage
> > >> and I think that BTRFS perhaps should consider doing something like
> > >> that
> > >> on it's official wiki as well
> > > 
> > > BTRFS also has a feature matrix. The links to it are in the "News"
> > > section
> > > however:
> > > 
> > > https://btrfs.wiki.kernel.org/index.php/Changelog#By_feature
> > 
> > I disagree, this is not a feature / stability matrix. It is a clearly a
> > changelog by kernel version.
> 
> It is a *feature* matrix. I fully said its not about stability, but about 
> implementation – I just wrote this a sentence after this one. There is no
> need  whatsoever to further discuss this as I never claimed that it is a
> feature / stability matrix in the first place.
> 
> > > Thing is: This just seems to be when has a feature been implemented
> > > matrix.
> > > Not when it is considered to be stable. I think this could be done with
> > > colors or so. Like red for not supported, yellow for implemented and
> > > green for production ready.
> > 
> > Exactly, just like the Nouveau matrix. It clearly shows what you can
> > expect from it.

I mentioned this matrix as a good *starting* point. And I think it would be 
easy to extent it:

Just add another column called "Production ready". Then research / ask about 
production stability of each feature. The only challenge is: Who is 
authoritative on that? I´d certainly ask the developer of a feature, but I´d 
also consider user reports to some extent.

Maybe thats the real challenge.

If you wish, I´d go through each feature there and give my own estimation. But 
I think there are others who are deeper into this.

I do think for example that scrubbing and auto raid repair are stable, except 
for RAID 5/6. Also device statistics and RAID 0 and 1 I consider to be stable. 
I think RAID 10 is also stable, but as I do not run it, I don´t know. For me 
also skinny-metadata is stable. For me so far even compress=lzo seems to be 
stable, but well for others it may not.

Since what kernel version? Now, there you go. I have no idea. All I know I 
started BTRFS with Kernel 2.6.38 or 2.6.39 on my laptop, but not as RAID 1 at 
that time.

See, the implementation time of a feature is much easier to assess. Maybe 
thats part of the reason why there is not stability matrix: Maybe no one 
*exactly* knows *for sure*. How could you? So I would even put a footnote on 
that "production ready" row explaining "Considered to be stable by developer 
and user oppinions".

Of course additionally it would be good to read about experiences of corporate 
usage of BTRFS. I know at least Fujitsu, SUSE, Facebook, Oracle are using it. 
But I don´t know in what configurations and with what experiences. One Oracle 
developer invests a lot of time to bring BTRFS like features to XFS and RedHat 
still favors XFS over BTRFS, even SLES defaults to XFS for /home and other non 
/-filesystems. That also tells a story.

Some ideas you can get from SUSE releasenotes. Even if you do not want to use 
it, it tells something and I bet is one of the better sources of information 
regarding your question you can get at this time. Cause I believe SUSE 
developers invested some time to assess the stability of features. Cause they 
would carefully assess what they can support in enterprise environments. There 
is also someone from Fujitsu who shared experiences in a talk, I can search 
the URL to the slides again.

I bet Chris Mason and other BTRFS developers at Facebook have some idea on 
what they use within Facebook as well. To what extent they are allowed to talk 
about it… I don´t know. My personal impression is that as soon as Chris went 
to Facebook he became quite quiet. Maybe just due to being busy. Maybe due to 
Facebook being concerned much more about the privacy of itself than of its 
users.

Thanks,
-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is stability a joke?

[Martin Steigerwald]

Am Sonntag, 11. September 2016, 13:21:30 CEST schrieb Zoiled:
> Martin Steigerwald wrote:
> > Am Sonntag, 11. September 2016, 10:55:21 CEST schrieb Waxhead:
> >> I have been following BTRFS for years and have recently been starting to
> >> use BTRFS more and more and as always BTRFS' stability is a hot topic.
> >> Some says that BTRFS is a dead end research project while others claim
> >> the opposite.
> > 
> > First off: On my systems BTRFS definately runs too stable for a research
> > project. Actually: I have zero issues with stability of BTRFS on *any* of
> > my systems at the moment and in the last half year.
> > 
> > The only issue I had till about half an year ago was BTRFS getting stuck
> > at
> > seeking free space on a highly fragmented RAID 1 + compress=lzo /home.
> > This
> > went away with either kernel 4.4 or 4.5.
> > 
> > Additionally I never ever lost even a single byte of data on my own BTRFS
> > filesystems. I had a checksum failure on one of the SSDs, but BTRFS RAID 1
> > repaired it.
> > 
> > 
> > Where do I use BTRFS?
> > 
> > 1) On this ThinkPad T520 with two SSDs. /home and / in RAID 1, another
> > data
> > volume as single. In case you can read german, search blog.teamix.de for
> > BTRFS.
> > 
> > 2) On my music box ThinkPad T42 for /home. I did not bother to change / so
> > far and may never to so for this laptop. It has a slow 2,5 inch harddisk.
> > 
> > 3) I used it on Workstation at work as well for a data volume in RAID 1.
> > But workstation is no more (not due to a filesystem failure).
> > 
> > 4) On a server VM for /home with Maildirs and Owncloud data. /var is still
> > on Ext4, but I want to migrate it as well. Whether I ever change /, I
> > don´t know.
> > 
> > 5) On another server VM, a backup VM which I currently use with
> > borgbackup.
> > With borgbackup I actually wouldn´t really need BTRFS, but well…
> > 
> > 6) On *all* of my externel eSATA based backup harddisks for snapshotting
> > older states of the backups.
> 
> In other words, you are one of those who claim the opposite :) I have
> also myself run btrfs for a "toy" filesystem since 2013 without any
> issues, but this is more or less irrelevant since some people have
> experienced data loss thanks to unstable features that are not clearly
> marked as such.
> And making a claim that you have not lost a single byte of data does not
> make sense, how did you test this? SHA256 against a backup? :)

Do you have any proof like that with *any* other filesystem on Linux?

No, my claim is a bit weaker: BTRFS own scrubbing feature and well no I/O 
errors on rsyncing my data over to the backup drive - BTRFS checks checksum on 
read as well –, and yes I know BTRFS uses a weaker hashing algorithm, I think 
crc32c. Yet this is still more than what I can say about *any* other 
filesystem I used so far. Up to my current knowledge neither XFS nor Ext4/3 
provide data checksumming. They do have metadata checksumming and I found 
contradicting information on whether XFS may support data checksumming in the 
future, but up to now, no *proof* *whatsoever* from side of the filesystem 
that the data is, what it was when I saved it initially. There may be bit 
errors rotting on any of your Ext4 and XFS filesystem without you even 
noticing for *years*. I think thats still unlikely, but it can happen, I have 
seen this years ago after restoring a backup with bit errors from a hardware 
RAID controller.

Of course, I rely on the checksumming feature within BTRFS – which may have 
errors. But even that is more than with any other filesystem I had before.

And I do not scrub daily, especially not the backup disks, but for any scrubs 
up to now, no issues. So, granted, my claim has been a bit bold. Right now I 
have no up-to-this-day scrubs so all I can say is that I am not aware of any 
data losses up to the point in time where I last scrubbed my devices. Just 
redoing the scrubbing now on my laptop.

> >> The Debian wiki for BTRFS (which is recent by the way) contains a bunch
> >> of warnings and recommendations and is for me a bit better than the
> >> official BTRFS wiki when it comes to how to decide what features to use.
> > 
> > Nice page. I wasn´t aware of this one.
> > 
> > If you use BTRFS with Debian, I suggest to usually use the recent backport
> > kernel, currently 4.6.
> > 
> > Hmmm, maybe I better remove that compress=lzo mount option. Never saw any
> > issue with it, tough. Will research what they say about it.
> 
> My point exactly: You did not know about this and hence the risk of your
> data being gnawed on.

Well I do follow BTRFS mailinglist to some extent and I recommend anyone who 
uses BTRFS in production to do this. And: So far I see no data loss from using 
that option and for me personally it is exactly that what counts. J

Still: An information on what features are stable with what version of kernel 
and btrfs-progrs is important. I totally agree with that and there is not the 
slighted need to discuss about 

Re: Is stability a joke?

[Martin Steigerwald]

Am Sonntag, 11. September 2016, 10:55:21 CEST schrieb Waxhead:
> I have been following BTRFS for years and have recently been starting to
> use BTRFS more and more and as always BTRFS' stability is a hot topic.
> Some says that BTRFS is a dead end research project while others claim
> the opposite.

First off: On my systems BTRFS definately runs too stable for a research 
project. Actually: I have zero issues with stability of BTRFS on *any* of my 
systems at the moment and in the last half year.

The only issue I had till about half an year ago was BTRFS getting stuck at 
seeking free space on a highly fragmented RAID 1 + compress=lzo /home. This 
went away with either kernel 4.4 or 4.5.

Additionally I never ever lost even a single byte of data on my own BTRFS 
filesystems. I had a checksum failure on one of the SSDs, but BTRFS RAID 1 
repaired it.


Where do I use BTRFS?

1) On this ThinkPad T520 with two SSDs. /home and / in RAID 1, another data 
volume as single. In case you can read german, search blog.teamix.de for 
BTRFS.

2) On my music box ThinkPad T42 for /home. I did not bother to change / so far 
and may never to so for this laptop. It has a slow 2,5 inch harddisk.

3) I used it on Workstation at work as well for a data volume in RAID 1. But 
workstation is no more (not due to a filesystem failure).

4) On a server VM for /home with Maildirs and Owncloud data. /var is still on 
Ext4, but I want to migrate it as well. Whether I ever change /, I don´t know.

5) On another server VM, a backup VM which I currently use with borgbackup. 
With borgbackup I actually wouldn´t really need BTRFS, but well…

6) On *all* of my externel eSATA based backup harddisks for snapshotting older 
states of the backups.

> The Debian wiki for BTRFS (which is recent by the way) contains a bunch
> of warnings and recommendations and is for me a bit better than the
> official BTRFS wiki when it comes to how to decide what features to use.

Nice page. I wasn´t aware of this one.

If you use BTRFS with Debian, I suggest to usually use the recent backport 
kernel, currently 4.6.

Hmmm, maybe I better remove that compress=lzo mount option. Never saw any 
issue with it, tough. Will research what they say about it.

> The Nouveau graphics driver have a nice feature matrix on it's webpage
> and I think that BTRFS perhaps should consider doing something like that
> on it's official wiki as well

BTRFS also has a feature matrix. The links to it are in the "News" section 
however:

https://btrfs.wiki.kernel.org/index.php/Changelog#By_feature

Thing is: This just seems to be when has a feature been implemented matrix. 
Not when it is considered to be stable. I think this could be done with colors 
or so. Like red for not supported, yellow for implemented and green for 
production ready.

Another hint you can get by reading SLES 12 releasenotes. SUSE dares to 
support BTRFS since quite a while – frankly, I think for SLES 11 SP 3 this was 
premature, at least for the initial release without updates, I have a VM that 
with BTRFS I can break very easily having BTRFS say it is full, while it is 
has still 2 GB free. But well… this still seems to happen for some people 
according to the threads on BTRFS mailing list.

SUSE doesn´t support all of BTRFS. They even put features they do not support 
behind a "allow_unsupported=1" module option:

https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-314697

But they even seem to contradict themselves by claiming they support RAID 0, 
RAID 1 and RAID10, but not RAID 5 or RAID 6, but then putting RAID behind that 
module option – or I misunderstood their RAID statement

"Btrfs is supported on top of MD (multiple devices) and DM (device mapper) 
configurations. Use the YaST partitioner to achieve a proper setup. 
Multivolume Btrfs is supported in RAID0, RAID1, and RAID10 profiles in SUSE 
Linux Enterprise 12, higher RAID levels are not yet supported, but might be 
enabled with a future service pack."

and they only support BTRFS on MD for RAID. They also do not support 
compression yet. They even do not support big metadata.

https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-317221

Interestingly enough RedHat only supports BTRFS as a technology preview, even 
with RHEL 7.

> For example something along the lines of  (the statuses are taken
> our of thin air just for demonstration purposes)

I´d say feel free to work with the feature matrix already there and fill in 
information about stability. I think it makes sense tough to discuss first on 
how to do it with still keeping it manageable.

Thanks,
-- 
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Is stability a joke?

[Steven Haigh]

This. So much this.

After being burned badly by the documentation / wiki etc making RAID5/6
seem stable, I think its a joke how the features of BTRFS are promoted.

A lot that is marked as 'Implemented' or 'Complete' is little more than
a "In theory, it works" - but will eat your data.

Having a simple reference as to the status of what is going on, and what
will eat your data would probably save Tb's of data in the next few
months and lots of reputation for BTRFS...

On 11/09/16 18:55, Waxhead wrote:
> I have been following BTRFS for years and have recently been starting to
> use BTRFS more and more and as always BTRFS' stability is a hot topic.
> Some says that BTRFS is a dead end research project while others claim
> the opposite.
> 
> Taking a quick glance at the wiki does not say much about what is safe
> to use or not and it also points to some who are using BTRFS in production.
> While BTRFS can apparently work well in production it does have some
> caveats, and finding out what features is safe or not can be problematic
> and I especially think that new users of BTRFS can easily be bitten if
> they do not do a lot of research on it first.
> 
> The Debian wiki for BTRFS (which is recent by the way) contains a bunch
> of warnings and recommendations and is for me a bit better than the
> official BTRFS wiki when it comes to how to decide what features to use.
> 
> The Nouveau graphics driver have a nice feature matrix on it's webpage
> and I think that BTRFS perhaps should consider doing something like that
> on it's official wiki as well
> 
> For example something along the lines of  (the statuses are taken
> our of thin air just for demonstration purposes)
> 
> Kernel version 4.7
> +++-+---+---++---++
> 
> | Feature / Redundancy level | Single | Dup | Raid0 | Raid1 | Raid10 |
> Raid5 | Raid 6 |
> +++-+---+---++---++
> 
> | Subvolumes | Ok | Ok  | Ok| Ok| Ok   | Bad
>   | Bad|
> +++-+---+---++---++
> 
> | Snapshots  | Ok | Ok  | Ok| Ok| Ok |
> Bad   | Bad|
> +++-+---+---++---++
> 
> | LZO Compression| Bad(1) | Bad | Bad   | Bad(2)| Bad|
> Bad   | Bad|
> +++-+---+---++---++
> 
> | ZLIB Compression   | Ok | Ok  | Ok| Ok| Ok |
> Bad   | Bad|
> +++-+---+---++---++
> 
> | Autodefrag | Ok | Bad | Bad(3)| Ok| Ok |
> Bad   | Bad|
> +++-+---+---++---++
> 
> 
> (1) Some explanation here...
> (2) Some explanation there
> (3) And some explanation elsewhere...
> 
> ...etc...etc...
> 
> I therefore would like to propose that some sort of feature / stability
> matrix for the latest kernel is added to the wiki preferably somewhere
> where it is easy to find. It would be nice to archive old matrix'es as
> well in case someone runs on a bit older kernel (we who use Debian tend
> to like older kernels). In my opinion it would make things bit easier
> and perhaps a bit less scary too. Remember if you get bitten badly once
> you tend to stay away from from it all just in case, if you on the other
> hand know what bites you can safely pet the fluffy end instead :)


-- 
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



signature.asc
Description: OpenPGP digital signature

Is stability a joke?

[Waxhead]

I have been following BTRFS for years and have recently been starting to 
use BTRFS more and more and as always BTRFS' stability is a hot topic.
Some says that BTRFS is a dead end research project while others claim 
the opposite.


Taking a quick glance at the wiki does not say much about what is safe 
to use or not and it also points to some who are using BTRFS in production.
While BTRFS can apparently work well in production it does have some 
caveats, and finding out what features is safe or not can be problematic 
and I especially think that new users of BTRFS can easily be bitten if 
they do not do a lot of research on it first.


The Debian wiki for BTRFS (which is recent by the way) contains a bunch 
of warnings and recommendations and is for me a bit better than the 
official BTRFS wiki when it comes to how to decide what features to use.


The Nouveau graphics driver have a nice feature matrix on it's webpage 
and I think that BTRFS perhaps should consider doing something like that 
on it's official wiki as well


For example something along the lines of  (the statuses are taken 
our of thin air just for demonstration purposes)


Kernel version 4.7
+++-+---+---++---++
| Feature / Redundancy level | Single | Dup | Raid0 | Raid1 | Raid10 | 
Raid5 | Raid 6 |

+++-+---+---++---++
| Subvolumes | Ok | Ok  | Ok| Ok| Ok   | Bad 
  | Bad|

+++-+---+---++---++
| Snapshots  | Ok | Ok  | Ok| Ok| Ok | 
Bad   | Bad|

+++-+---+---++---++
| LZO Compression| Bad(1) | Bad | Bad   | Bad(2)| Bad| 
Bad   | Bad|

+++-+---+---++---++
| ZLIB Compression   | Ok | Ok  | Ok| Ok| Ok | 
Bad   | Bad|

+++-+---+---++---++
| Autodefrag | Ok | Bad | Bad(3)| Ok| Ok | 
Bad   | Bad|

+++-+---+---++---++

(1) Some explanation here...
(2) Some explanation there
(3) And some explanation elsewhere...

...etc...etc...

I therefore would like to propose that some sort of feature / stability 
matrix for the latest kernel is added to the wiki preferably somewhere 
where it is easy to find. It would be nice to archive old matrix'es as 
well in case someone runs on a bit older kernel (we who use Debian tend 
to like older kernels). In my opinion it would make things bit easier 
and perhaps a bit less scary too. Remember if you get bitten badly once 
you tend to stay away from from it all just in case, if you on the other 
hand know what bites you can safely pet the fluffy end instead :)

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html