<p dir="ltr">I can't fathom what went wrong. I've got hundreds of TB on XFS and never lost a bit. </p>
<p dir="ltr">I'm still working on video conference capability so a remote speaker is an option at some point.</p>
<div class="gmail_quote">On Jun 7, 2015 11:15 AM, "Michael Trausch" <<a href="mailto:mike@trausch.us">mike@trausch.us</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You've already heard my XFS nightmares. Anything labelled "production" that also eats my data in production before the first backup has even finished running is equal to three strikes in my book all on its own. But I assumed it was user error and reinstalled and placed the data back. It happened again.<br>
<br>
I've said it before, and I will say it again: I am a lazy person. I want things done once, done right, and off my plate. That's what I'd trusted the SGI FS in the first place. Of course it should've worked.<br>
<br>
But, btrfs (unlike XFS) actually has all the major ZFS features, all it's flexibility, and none of the command complexity. The code changes just as much in the unified ext2/3/4 driver as it does in the btrfs driver in the last several releases. But ext2/3/4 requires LVM for any type of flexibility and you still have to juggle space.<br>
<br>
Btrfs subvolumes are fast, free, and allows you to have an arbitrary number of filesystem roots in the same volume pool. Organization and storage allocation are simplified and do not require juggling. As flexible as LVM, but without the waiting for bits to move. Because none need to.<br>
<br>
Backup? Snapshot and back that up. Delta between snapshots? Snap again and use "btrfs send" which allows you to keep even large filesystems in sync between disaster recovery zones.<br>
<br>
I could put together a talk, but due to some relatively newly acquired issues related to my surgery last year, I'd either need to present it as a video with remote attendance or give the assembled talk to another speaker.<br>
<br>
Sent from my iPhone<br>
<br>
> On Jun 7, 2015, at 8:02 AM, Jim Kinney <<a href="mailto:jkinney@jimkinney.us">jkinney@jimkinney.us</a>> wrote:<br>
><br>
> There's a reason (several, actually) the default filesystem on RHEL and derivatives is now xfs. It has much of the happy stuff associated with zfs but none of the pain of half the RAM for filesystem. It scales larger than ext4 can (when are they going to fix that bug ?). It can handle multi-TB file sizes and not blink. And it's very mature. It plays very nicely with LVM.<br>
><br>
> I've become rather fond of the RedHat way of /boot is a partition and all else is under LVM. Makes it possible and rather painless to adjust things around and needs change over the life of a machine. Need more swap? No problem. Need a new partition for a special use? No problem. Need a snapshot before a huge pile of weird changes? No problem.<br>
<br>
_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
</blockquote></div>