Significance of high number of mails on this list?

Significance of high number of mails on this list?

[Shriramana Sharma]

Hello. People on this list have been kind enough to reply to my
technical questions. However, seeing the high number of mails on this
list, esp with the title PATCH, I have a question about the
development itself:

Is this just an indication of a vibrant user/devel community [*] and
healthy development of many new nice features to eventually come out
in stable form later, or are we still at the fixing rough edges stage?
IOW what is the proportion of commits adding new features to those
stabilising/fixing features?

[* Since there is no separate btrfs-users vs brtfs-dev I'm not able to
gauge this difference either. i.e. if there were a dedicated -dev list
I might not be alarmed by a high number of mails indicating fast
development.]

Mostly I have read like "BTRFS is mostly stable but there might be a
few corner cases as yet unknown since this is a totally new generation
of FSs". But still given the volume of mails here I wanted to ask...
I'm sorry I realize I'm being a bit vague but I'm not sure how to
exactly express what I'm feeling about BTRFS right now...

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Significance of high number of mails on this list?

[Duncan]

Shriramana Sharma posted on Thu, 21 Aug 2014 08:52:52 +0530 as excerpted:

> Hello. People on this list have been kind enough to reply to my
> technical questions. However, seeing the high number of mails on this
> list, esp with the title PATCH, I have a question about the development
> itself:
> 
> Is this just an indication of a vibrant user/devel community [*] and
> healthy development of many new nice features to eventually come out in
> stable form later, or are we still at the fixing rough edges stage?
> IOW what is the proportion of commits adding new features to those
> stabilising/fixing features?
> 
> [* Since there is no separate btrfs-users vs brtfs-dev I'm not able to
> gauge this difference either. i.e. if there were a dedicated -dev list I
> might not be alarmed by a high number of mails indicating fast
> development.]
> 
> Mostly I have read like "BTRFS is mostly stable but there might be a few
> corner cases as yet unknown since this is a totally new generation of
> FSs". But still given the volume of mails here I wanted to ask... I'm
> sorry I realize I'm being a bit vague but I'm not sure how to exactly
> express what I'm feeling about BTRFS right now...

Good question, but certainly one where opinions are likely to differ.  Of 
course there a more or less official answer on the wiki 
( btrfs.wiki.kernel.org ), but given the previous research the level of 
the questions you've been asking demonstrate, I expect you've seen that 
and well, it's simply not at the level of detail you find yourself 
needing at this point, so here you are, asking for more detail and, I 
guess, personal opinion.

I'm going to frame my own answer as several general "observations of 
fact" which I don't believe there's likely to be much dispute over, then 
explain them, then follow that with my own opinion.

"Observations of fact" enumerated:

1) Definitions of "stable" differ.
2) Mailing lists distort reality.
3) Previous btrfs warnings have been removed.
4) Two major recent stability-affecting bugs.
5) Some bits of btrfs more stable than others.

"Observations of fact" explained:

1) Definitions of "stable" differ.

There's the "stable" that people like me sometimes simply omit the "b" 
from and call stale, and there's "dogfoodable" stable.

In distro terms, sta(b)le is RHEL 5 or Debian old-stable.  In filesystem 
terms, it's ext3, as ext4 is only now beginning to look stable.

"Dogfoodable" stable refers to the point at which developers and early 
testers find software stable enough to actually use in their ordinary 
daily routine.

I can't see anyone arguing that btrfs meets the sta(b)le standard or that 
it's any closer than a few years out.  OTOH, I guess most regulars here 
have found btrfs "dogfoodable stable" for some time.  But "stable" for 
most people means something in between, and just where btrfs is in that 
in between, is where the debate is.

2) Filesystem mailing lists distort reality.

It's exceeding difficult to draw accurate stability conclusions (well, 
beyond the sta(b)le level) from a filesystem's mailing list.  If the 
filesystem's under active development, there /will/ be numbers of active 
bugs reported, some of which will look pretty bad from the outside or 
simple sysadmin's perspective, and lots of patches floating around in 
various stages of development as well.  An uninitiated outsider's 
reaction will almost certainly be "and THIS is what they call STABLE?"

But that's a fairly obvious first-order conclusion.  The immediate 
natural reaction is to discount it, but it's just as easy to over-
discount and see it as more stable than it is.  Accurately calibrating 
the amount of discount without other information is basically impossible, 
so other information must be used as a primary gauge, with the mailing 
list possibly used as a reality check on /that/.

OTOH, I'd expect a fully mature and stable (post-mature? sta(b)le?) 
filesystem, without much /need/ for new development, only maintenance of 
current state, to have a much quieter list.  Obviously as a filesystem 
falls into obsolescence and disuse, it'll have a quieter list as well.

3) Previous btrfs warnings have been removed.

In the last few kernel cycles the previous more or less official "btrfs 
will eat your babies" level instability warning has been removed, from 
the kernel option description, to the wording used on the wiki, to the 
warning in the manpages and printed by mkfs.btrfs, if there's any warning 
at all left, it's far less strident than it was.

Some here believe the complete removal of such warnings has been 
premature, altho arguably it was time to tone them down.

4) Two severe stability-affecting bugs have recently been traced and have 
patches working thru the pipeline as we speak.

One of these bugs has been there since very near the beginning, but 
happened to only be triggered rarely, the reason it wasn't caught until 
now.  The patch is to be applied to stable going back as far as stable 
series (with btrfs) go and should already be in 3.17-development (which 
I've not switched to yet so I can't say for sure).

The other of these bugs was introduced with the switch from btrfs-kernel 
private worker threads before and in 3.14, to the generic kworker thread 
facility in 3.15, and apparently triggers only for those using btrfs 
compression.  It has thus been there for the full 3.15 and 3.16 kernel 
cycles, with a fix to go into 3.17 (again, I'm not sure if it's there 
yet) and presumably be backported to 3.16. (3.15 isn't a long-term-
support kernel and is thus nearing/at EOL, and isn't likely to get the 
patch.)  This bug hit enough people hard enough that the current 
recommendation is to stick with 3.14 until 3.16-stable and 3.17-
development have the fix.  I've not been as severely affected, perhaps 
due to my general desktop use-case and the fact that I'm on ssd.

Of course such bugs hit much longer term stable kernel subsystems too -- 
there was recently an mdraid bug in this category that hit the news, 
but...

5) Some bits of btrfs are unquestionably more "stable" than others.

The btrfs raid5/6 code, for instance, isn't even complete yet, let alone 
stable.

The longest implemented and most well tested stable code is the basic, 
single device btrfs in default single-mode data, dup-mode metadata, 
configuration, in ordinary filesystem feature replacement mode -- no 
special use of any of the fancy btrfs specific features and no quota 
usage.  This generally works quite well in normal operation.

Multi-device raid0/1/10 modes are now reasonably stable as well and don't 
see a lot of serious normal operational problems reported.  Device add/
delete/replace isn't quite as stable however, and does see bugs reported 
from time to time.

Quota support and more advanced btrfs specific features such as 
snapshotting and send/receive are less stable and have more problems.  
Even the relatively critical kworker threads related bug mentioned above 
apparently only affected those using the btrfs specific transparent 
compression feature, which wouldn't be included in an apples to apples 
comparison with traditional filesystems since they don't normally have 
such a feature.

Of course, without the btrfs specific features there's little or no 
reason to pick btrfs over other filesystems, so the stability of those 
advanced filesystem features matters!

My opinion:

Bottom line, keep your backups tested and ready for use if necessary, 
know the stability level of the filesystem device modes and features you 
use and be prepared accordingly, keep current on your kernels unless you 
have a specific reason not to (like the current kworker related bug 
keeping many to 3.14 until it's fixed), and keep current with btrfs 
current status on the mailing list, and you shouldn't have too much 
problem.

Of course that's a stiff set of requirements for widely deployed "stable" 
use as most people simply aren't used to having to do all that to support 
their "stable" systems, which is why I'm among those who believe 
stripping the previous warnings was somewhat premature, altho toning them 
down a bit was arguably appropriate.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Significance of high number of mails on this list?

[Martin Steigerwald]

Hello!

Am Donnerstag, 21. August 2014, 08:52:52 schrieb Shriramana Sharma:
> Hello. People on this list have been kind enough to reply to my
> technical questions. However, seeing the high number of mails on this
> list, esp with the title PATCH, I have a question about the
> development itself:
> 
> Is this just an indication of a vibrant user/devel community [*] and
> healthy development of many new nice features to eventually come out
> in stable form later, or are we still at the fixing rough edges stage?
> IOW what is the proportion of commits adding new features to those
> stabilising/fixing features?

Oh, well, sometimes I can guess from the patch descriptions whether this is 
more of a fix or more of a feature. And on what I see in the last week or do 
its mostly stabilization and fixing work. Also the last pull request was more 
about fixes.

Which is good, since fixes help to stabilize BTRFS further.

> [* Since there is no separate btrfs-users vs brtfs-dev I'm not able to
> gauge this difference either. i.e. if there were a dedicated -dev list
> I might not be alarmed by a high number of mails indicating fast
> development.]

Why would that make a difference?
 
> Mostly I have read like "BTRFS is mostly stable but there might be a
> few corner cases as yet unknown since this is a totally new generation
> of FSs". But still given the volume of mails here I wanted to ask...
> I'm sorry I realize I'm being a bit vague but I'm not sure how to
> exactly express what I'm feeling about BTRFS right now...

Well, I do not really get what you are after. What is your *intention*?

Do you want to try out BTRFS? Do you want to use BTRFS in production use? Do 
you want to use BTRFS on a desktop, laptop, server? What BTRFS features do you 
want to use? Just a plain volume or RAID 1 and so on…

On any account if you plan to use BTRFS I strongly recommend to be subscribed 
to this mailing list and be willing to deal with issues.

There are hangs reported happening on 3.15 and 3.16 in space full situations. 
I long thought 3.14 would be safe, but there have been problem reports as 
well.

That said, none of my BTRFS filesystems corrupted itself so far. I have a 
slight glitch on /home BTRFS RAID 1 I was not yet able to repair, but 
scrubbing tells me my data is good. And at keeping stored data fine and healthy 
all of my BTRFS installations have been good at. According to scrubbing I 
never ever lost a single byte on *any* BTRFS drive. Except a BTRFS RAID 0 over 
16 or 18 SAS disks which went completely bust quite some time ago, but first 
this could have been a hardware issue and second maybe btrfs-zero-log I wasn´t 
aware of could have helped.

I close with a summary on where I use BTRFS right now:

- my main laptop is except for /boot completely BTRFS, partly RAID 1 on two 
SSDs, partly single drived. It is BTRFS since I got it. So more than 3 years. 
RAID 1 since four months or so. I used snapshots manually there, but as the 
lockups seem to happen more easily as BTRFS fills up more quickly, I didn´t. I 
think I will use snapshots again now I am testing some patches to fix those 
lockups.

- my old music laptop was BTRFS except for /boot for years.

- I just moved my new music laptop /home to BTRFS as well, / and /boot are 
Ext4. I did you by restoring from backup instead of using btrfs-convert

- I have two large external eSATA HDDs which are BTRFS as well. One since more 
than a year. I use snapshots manuelly there to hold old backups. Still doing 
backup by rsync so far.

- I recently moved part of my server VM onto BTRFS with several subvolumes. 
/home and /srv are on it already. /home with maildir stuff and /srv with 
owncloud data storage. I will be moving /var soon as well, I think. I use 
snapshots manually there.

Many of my BTRFS file system is not all of them use lzo compression. All use 
space_cache. Most of them use big metadata and skinny extents and ext ref for 
more hardlinks as well.

So while BTRFS seems to keep already stored data safe for me very reliably, I 
do have issues with reliability during runtime on *some* BTRFS setups, mostly 
those where the trees of BTRFS easily allocate all of the volume, so somewhat 
heavily used *and* somewhat space constrained setups, where automatic tree 
rebalancing would be helpful. These require manual maintenance for now from 
time to time.


I know some are using btrfs send and receive already as well. I didn´t yet got 
to set it up. Also see the nice slides by Marc Merlin.

http://www.phoronix.com/scan.php?page=news_item&px=MTc2Njk

http://events.linuxfoundation.org/sites/events/files/slides/Btrfs.pdf

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

Re: Significance of high number of mails on this list?

[Shriramana Sharma]

Hello people. Thank you for your detailed replies, esp Duncan.

In essence, I plan on using BTRFS for my production data -- mainly
programs/documents I write in connection with my academic research.
I'm not a professional sysadmin and I'm not running a business server.
I'm just managing my own data, and as I have mentioned, my chief
reason for looking at BTRFS is the ease of snapshots and backups using
send/receive.

It is clear now that snapshots are by and large stable but
send/receive is not. But, IIUC, even if send/receive fails I still
have the older data which is not overwritten due to COW and atomic
operations, and I can always retry send/receive again. Is this
correct?

If yes, then I guess I can take the plunge but ensure I have daily
backups (which BTRFS itself should help me do easily).


-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: Significance of high number of mails on this list?

[Marc MERLIN]

On Fri, Aug 22, 2014 at 09:10:55AM +0530, Shriramana Sharma wrote:
> Hello people. Thank you for your detailed replies, esp Duncan.
> 
> In essence, I plan on using BTRFS for my production data -- mainly
> programs/documents I write in connection with my academic research.
> I'm not a professional sysadmin and I'm not running a business server.
> I'm just managing my own data, and as I have mentioned, my chief
> reason for looking at BTRFS is the ease of snapshots and backups using
> send/receive.
> 
> It is clear now that snapshots are by and large stable but
> send/receive is not. But, IIUC, even if send/receive fails I still

I wouldn't quite agree with that, btrfs send/receive has been working
fairly well for me on multiple systems for multiple backups per day.
My laptop oftens fails to complete a btrfs send to my server remotely
over the internet, and it recovers on its own a the next cron run and
sends the a newer bigger diff next time and it just works.

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

Re: Significance of high number of mails on this list?

[Konstantinos Skarlatos]

On 22/8/2014 6:40 πμ, Shriramana Sharma wrote:
> Hello people. Thank you for your detailed replies, esp Duncan.
>
> In essence, I plan on using BTRFS for my production data -- mainly
> programs/documents I write in connection with my academic research.
> I'm not a professional sysadmin and I'm not running a business server.
> I'm just managing my own data, and as I have mentioned, my chief
> reason for looking at BTRFS is the ease of snapshots and backups using
> send/receive.
>
> It is clear now that snapshots are by and large stable but
> send/receive is not. But, IIUC, even if send/receive fails I still
> have the older data which is not overwritten due to COW and atomic
> operations, and I can always retry send/receive again. Is this
> correct?
>
> If yes, then I guess I can take the plunge but ensure I have daily
> backups (which BTRFS itself should help me do easily).
>
>
I would stay with rsync for a while, because there is always the 
possibility of a bug that corrupts both your primary filesystem and your 
backup one, or send propagating corruption from one filesystem to 
another (Or maybe I am too paranoid, it would be good if we could have 
the opinion of a btrfs developer on this)

I would also suggest lsyncd if rsync runs become slow due to too many 
files and directories, or you have something like my use case, where i 
have filesystems with millions of files and my backup servers are a few 
km away and reachable over relatively slow wireless links.

Finaly, be sure to use the --inplace option of rsync.

-- 
Konstantinos Skarlatos

Re: Significance of high number of mails on this list?

[Duncan]

Konstantinos Skarlatos posted on Fri, 22 Aug 2014 09:56:55 +0300 as
excerpted:

> I would stay with rsync for a while, because there is always the
> possibility of a bug that corrupts both your primary filesystem and your
> backup one, or send propagating corruption from one filesystem to
> another (Or maybe I am too paranoid, it would be good if we could have
> the opinion of a btrfs developer on this)

No claim to be a dev, btrfs or otherwise, here, but I believe in this 
case you /are/ "being too paranoid."

Both btrfs send and receive only deal with data/metadata they know how to 
deal with.  If it's corrupt in some way or if they don't understand it, 
they don't send/write it, they fail.

IOW, if it works without error it's as guaranteed to be golden as these 
things get.  The problem is that it doesn't always work without error in 
the first place, sometimes it /does/ fail.  In that instance you can 
always try again as the existing data/metadata shouldn't be damaged, but 
if it keeps failing you may have to try something else, rsync, etc.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Significance of high number of mails on this list?

[Filipe David Manana]

On Fri, Aug 22, 2014 at 8:35 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> Konstantinos Skarlatos posted on Fri, 22 Aug 2014 09:56:55 +0300 as
> excerpted:
>
>> I would stay with rsync for a while, because there is always the
>> possibility of a bug that corrupts both your primary filesystem and your
>> backup one, or send propagating corruption from one filesystem to
>> another (Or maybe I am too paranoid, it would be good if we could have
>> the opinion of a btrfs developer on this)
>
> No claim to be a dev, btrfs or otherwise, here, but I believe in this
> case you /are/ "being too paranoid."
>
> Both btrfs send and receive only deal with data/metadata they know how to
> deal with.  If it's corrupt in some way or if they don't understand it,
> they don't send/write it, they fail.

Most of the time yes, however we have at least 1 know bug that affects
3.14.x only where send silently corrupts file data (replaces valid
data with zeroes) at the destination:

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=766b5e5ae78dd04a93a275690a49e23d7dcb1f39

The fix landed in 3.15, but wasn't backported to 3.14.x yet (adding
Chris to cc).

>
> IOW, if it works without error it's as guaranteed to be golden as these
> things get.  The problem is that it doesn't always work without error in
> the first place, sometimes it /does/ fail.  In that instance you can
> always try again as the existing data/metadata shouldn't be damaged, but
> if it keeps failing you may have to try something else, rsync, etc.
>
> --
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."

Re: Significance of high number of mails on this list?

[Austin S Hemmelgarn]

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

On 2014-08-20 23:22, Shriramana Sharma wrote:
> Hello. People on this list have been kind enough to reply to my
> technical questions. However, seeing the high number of mails on this
> list, esp with the title PATCH, I have a question about the
> development itself:
> 
> Is this just an indication of a vibrant user/devel community [*] and
> healthy development of many new nice features to eventually come out
> in stable form later, or are we still at the fixing rough edges stage?
> IOW what is the proportion of commits adding new features to those
> stabilising/fixing features?
> 
> [* Since there is no separate btrfs-users vs brtfs-dev I'm not able to
> gauge this difference either. i.e. if there were a dedicated -dev list
> I might not be alarmed by a high number of mails indicating fast
> development.]
> 
> Mostly I have read like "BTRFS is mostly stable but there might be a
> few corner cases as yet unknown since this is a totally new generation
> of FSs". But still given the volume of mails here I wanted to ask...
> I'm sorry I realize I'm being a bit vague but I'm not sure how to
> exactly express what I'm feeling about BTRFS right now...
> 
Personally I'd say that BTRFS is 'stable' enough for light usage without
using stuff like quotas or RAID5/6.  So far, having used it since 3.10,
I've only once had a filesystem get corrupted when there wasn't some
serious underlying hardware issue (crashed disk, SATA controller
dropping random single sectors from writes, etc.), and it gives me much
better performance than what I previously used (ext4 on top of LVM).
As far as what to make of the volume of patches on the mailing list, I'd
say that that shouldn't be used as a measure of quality.  The ext4
mailing list is almost as busy on a regular basis, and people have been
using that in production for years, and the XFS mailing list gets much
higher volume of patches from time to time, and it's generally
considered the gold standard of a stable filesystem.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Significance of high number of mails on this list?

[Konstantinos Skarlatos]

On 22/8/2014 12:58 μμ, Filipe David Manana wrote:
> On Fri, Aug 22, 2014 at 8:35 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>> Konstantinos Skarlatos posted on Fri, 22 Aug 2014 09:56:55 +0300 as
>> excerpted:
>>
>>> I would stay with rsync for a while, because there is always the
>>> possibility of a bug that corrupts both your primary filesystem and your
>>> backup one, or send propagating corruption from one filesystem to
>>> another (Or maybe I am too paranoid, it would be good if we could have
>>> the opinion of a btrfs developer on this)
>> No claim to be a dev, btrfs or otherwise, here, but I believe in this
>> case you /are/ "being too paranoid."
>>
>> Both btrfs send and receive only deal with data/metadata they know how to
>> deal with.  If it's corrupt in some way or if they don't understand it,
>> they don't send/write it, they fail.
> Most of the time yes, however we have at least 1 know bug that affects
> 3.14.x only where send silently corrupts file data (replaces valid
> data with zeroes) at the destination:
>
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=766b5e5ae78dd04a93a275690a49e23d7dcb1f39
>
> The fix landed in 3.15, but wasn't backported to 3.14.x yet (adding
> Chris to cc).

I didnt know about this one, but bugs like this are exactly the reason 
somebody should be "paranoid" and not rush to use new features, 
especially when they concern their only backup to an experimental 
filesystem.


>
>> IOW, if it works without error it's as guaranteed to be golden as these
>> things get.  The problem is that it doesn't always work without error in
>> the first place, sometimes it /does/ fail.  In that instance you can
>> always try again as the existing data/metadata shouldn't be damaged, but
>> if it keeps failing you may have to try something else, rsync, etc.
>>
>> --
>> 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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>


-- 
Konstantinos Skarlatos

Re: Significance of high number of mails on this list?

[Marc MERLIN]

On Fri, Aug 22, 2014 at 09:56:55AM +0300, Konstantinos Skarlatos wrote:
> I would stay with rsync for a while, because there is always the
> possibility of a bug that corrupts both your primary filesystem and
> your backup one, or send propagating corruption from one filesystem
> to another (Or maybe I am too paranoid, it would be good if we could
> have the opinion of a btrfs developer on this)

btrfs send will not corrupt your primary filesystem, it takes a read
only subvolume and sends its data somewhere else.
At worst, it can (and has in the fact) create incorrect data on the
destination, and I've never seen a single report of it actually
corrupting the destination filesystem (the destination subvolume can
correct incorrect data, but that wouldn't corrupt the existing data on
the destination).

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

Re: Significance of high number of mails on this list?

[Duncan]

Filipe David Manana posted on Fri, 22 Aug 2014 10:58:33 +0100 as
excerpted:

> On Fri, Aug 22, 2014 at 8:35 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>> Konstantinos Skarlatos posted on Fri, 22 Aug 2014 09:56:55 +0300 as
>> excerpted:
>>
>>> I would stay with rsync for a while, because there is always the
>>> possibility of a bug [...] (Or maybe I am too paranoid[)]
>>
>> I believe in this case you /are/ "being too paranoid."
>>
>> Both btrfs send and receive only deal with data/metadata they know how
>> to deal with.  If it's corrupt in some way or if they don't understand
>> it, they don't send/write it, they fail.
> 
> Most of the time yes, however we have at least 1 know bug that affects
> 3.14.x only where send silently corrupts file data (replaces valid data
> with zeroes) at the destination:
> 
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/
commit/?id=766b5e5ae78dd04a93a275690a49e23d7dcb1f39
> 
> The fix landed in 3.15, but wasn't backported to 3.14.x yet (adding
> Chris to cc).
> 
> 
>> IOW, if it works without error it's as guaranteed to be golden as these
>> things get.

Well, I /did/ say "as golden as these things get".  With even long stable 
subsystems such as mdraid having occasional data-risking bugs, and with 
btrfs in general not yet fully stable/mature...

But point taken.  That bug flew under my radar.  Thanks for mentioning it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Significance of high number of mails on this list?

[Rich Freeman]

On Fri, Aug 22, 2014 at 3:35 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>
> No claim to be a dev, btrfs or otherwise, here, but I believe in this
> case you /are/ "being too paranoid."
>
> Both btrfs send and receive only deal with data/metadata they know how to
> deal with.  If it's corrupt in some way or if they don't understand it,
> they don't send/write it, they fail.
>
> IOW, if it works without error it's as guaranteed to be golden as these
> things get.  The problem is that it doesn't always work without error in
> the first place, sometimes it /does/ fail.  In that instance you can
> always try again as the existing data/metadata shouldn't be damaged, but
> if it keeps failing you may have to try something else, rsync, etc.

Well, my main use-case for rsync right now is btrfs bug hoses my
filesystem, so it would be nice to have a daily full backup on
something other than btrfs so that it is unlikely to suffer the same
problem at the same time.

Using btrfs send with that backup would certainly be more efficient,
but it would defeat the purpose of the backup, which is to not be
btrfs.  I am already using mirroring in the event of drive failure,
and offsite cloud backups of critical data in the event of a larger
catastrophe.  Btrfs eating my data is a somewhat likely failure mode
in the grand scheme of things, so I protect against it so that I can
still have fun playing with btrfs without losing sleep.

I've actually restored from it once.  I suspect that I could have
fixed my ENOSPC problem without resorting to that, but the usual FAQ
solutions didn't work and I was running short on time, and that
particular filesystem was only 64GB anyway so it was a fast restore
(and that is why this filesystem is prone to ENOSPC in the first
place).

Oh, and I'm using rsnapshot, so I also get the benefit of a few days
worth of backups - almost as good as snapper, though in reality
obviously not the same thing.

--
Rich