[ale] New hard drive procedure

[Jim Kinney]

I can't fathom what went wrong. I've got hundreds of TB on XFS and never
lost a bit.

I'm still working on video conference capability so a remote speaker is an
option at some point.
On Jun 7, 2015 11:15 AM, "Michael Trausch" <mike at trausch.us> wrote:

> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Sent from my iPhone
>
> > On Jun 7, 2015, at 8:02 AM, Jim Kinney <jkinney at jimkinney.us> wrote:
> >
> > 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.
> >
> > 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.
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20150607/02e9da44/attachment.html>