[Cialug] BtrFS

[Hakan E. Duran]

I am sorry to be this late to this discussion. I didn't have a chance to
login to my email account since Wednesday.

Please find attached the pdf version of the presentation since the html
version did not look ideal in my attempts to view.

I borrowed the "half-finished" statement for btrfs from the first
reference cited at the last slide. It is a recent article published in
ars-technica, you can click it to follow the link if you would like to
read it. My intention was to not mislead people to believing that btrfs
is totally safe, causing harm to their data, especially since the
remaining of the presentation buffs btrfs for its awesome features. I
worried that I may end up advertising it too much if I don't emphasize
its weaknesses; I guess I may have exaggerated them instead. I for one
use btrfs as my daily driver on a single device for 3-4 years with no
data loss so far. I did not layer lvm and btrfs as mentioned but it may
negate some of btrfs' weaknesses with a relatively low cost of
performance.

One last point is that I feel less knowledgeable in this particular
field than you guys, as I may have mentioned before, and that was
another reason why I wanted to be more conservative in my presentation
while I was actually highly recommending it, partly because it saved my
whole CD database, which was the initial reason of presenting this
topic. Again, I guess I overshot a bit.

Thank you for the opportunity, I appreciate it. While I am glad that I
stirred up some discussion, I am sorry if I caused some confusion and
misled some in the opposite direction of what I intended, lol!

Hakan


On 21/10/21 11:09AM, Scott Yates wrote:
> All that and this note from the Wiki that Shane linked:
>
> Device *replace* and device *delete* insist on being able to read or
> reconstruct all data. If any read fails due to an IO error, the
> delete/replace operation is aborted and the administrator must remove or
> replace the damaged data before trying again.
>
> On Thu, Oct 21, 2021 at 11:07 AM Jim Cole <jrcole at gmail.com> wrote:
>
> >
> > https://www.phoronix.com/scan.php?page=news_item&px=Btrfs-Warning-RAID5-RAID6
> >
> >
> > On Thu, Oct 21, 2021 at 11:06 AM Theron Conrey <theron at conrey.org> wrote:
> >
> > > I think at some point striving for feature parity so something that
> > > continues to evolve misses the opportunities to speak to the strengths it
> > > currently has.  "half baked" may be unfair, but "unfinished" applies to
> > > everything, ZFS included.
> > >
> > > On Thu, Oct 21, 2021 at 11:03 AM Shane Nehring <shane at ntoast.com> wrote:
> > >
> > > > Because the goal of the project starting out was to make a GPL licensed
> > > ZFS
> > > > clone, and it's not there yet.
> > > >
> > > > On Thu, Oct 21, 2021, 10:54 L. V. Lammert <lvl at omnitec.net> wrote:
> > > >
> > > > > The thought distilled in my mind overnight, .. would love to hear
> > > > > responses:
> > > > >
> > > > > We have been using BtrFS for many years for it's invaluable recovery
> > > > > options as a root partition (and as the default root FS for
> > OpenSuSE),
> > > ..
> > > > > so I was understanbly confused at the presentation last night
> > > classifying
> > > > > it as "unfinished", or even "half baked".
> > > > >
> > > > > So, .. my question is this:
> > > > >
> > > > > Givem that the majority of installations ARE running a single device
> > > > (e.g.
> > > > > SAN, HW RAID, etc.), why would the ability to run multiple devices
> > have
> > > > > anything at all to do with the finish level of the file system??
> > > > >
> > > > > Really seems like a red herring to me, .. dissing a really useful
> > > > > filesystem with negatives that don't even apply?
> > > > >
> > > > >         TIA!
> > > > > _______________________________________________
> > > > > Cialug mailing list
> > > > > Cialug at cialug.org
> > > > > https://www.cialug.org/cgi-bin/mailman/listinfo/cialug
> > > > >
> > > > _______________________________________________
> > > > Cialug mailing list
> > > > Cialug at cialug.org
> > > > https://www.cialug.org/cgi-bin/mailman/listinfo/cialug
> > > >
> > > _______________________________________________
> > > Cialug mailing list
> > > Cialug at cialug.org
> > > https://www.cialug.org/cgi-bin/mailman/listinfo/cialug
> > >
> > _______________________________________________
> > Cialug mailing list
> > Cialug at cialug.org
> > https://www.cialug.org/cgi-bin/mailman/listinfo/cialug
> >
> _______________________________________________
> Cialug mailing list
> Cialug at cialug.org
> https://www.cialug.org/cgi-bin/mailman/listinfo/cialug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: btrfs.pdf
Type: application/pdf
Size: 211920 bytes
Desc: not available
URL: <http://www.cialug.org/pipermail/cialug/attachments/20211023/48d91bbc/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://www.cialug.org/pipermail/cialug/attachments/20211023/48d91bbc/attachment-0001.sig>