Btrfs

>>59536431
Thank you for not saying "redpill me".

btrfs is okay, but on a single-disk system I wouldn't bother unless you're really really keen on snapshots. The core feature (like ZFS) is that it says the hell with "layering violations" and does RAID and volume management along with the checksummed file system all in one. The idea being that the filesystem can verify all data against the checksum on read. On a single-disk system, this can inform you of, but not fix, data corruption. With redundancy though, because btrfs controls both the filesystem and the RAID layer (instead of ext4 and md being two different things that neither know nor care about each other's presence) it can ask the other disks to supply the same data, and then correct the data from redundancy on the fly in write it back.

It's had its issues though. Despite it being a decade old weird corner cases still come up where everything goes to hell. It's known to not play well with certain types of heavy random workloads - databases and VM images especially. You can fix that by turning off copy-on-write... and thus also losing all of btrfs's nice features, like checksumming and cheap snapshots. RAID 0 and RAID 1 work, but RAID 5 and 6 have a bad data-corruption bug that's gone unfixed for quite some time. (presumably because Facebook, who employs Chris Mason, the lead dev, doesn't care about it) Also some people have been tripped up by odd quirks, like how RAID 1 doesn't mean "data exists on all disks", it means "all data exists on two separate disks"

It sucks because a lot of hobbyist data-hoarders want essentially exactly what btrfs does: A checksummed FS/RAID layer that, unlike ZFS, can be expanded, contracted, and rebalanced easily. If only the damned thing worked right.

I would recommend just using ext4, anon. Newer isnt always better in filesystems. You don't want the latest features as much as you want battle-hardened bug-free code.

>>59536708
Seems legit. Thanks for the information.

File: hal.png (291KB, 500x469px) Image search: [Google]

291KB, 500x469px

>>59536708
post of the day

Honestly, don't bother with it. Snapshots are nice but there are a million other way to do backups and restore. Btrfs doesn't play well with existing tools (df returns wrong output) and you will randomly get 100%cpu load because it's reorganizing stuff, even when 50% of the drive is free, for whatever reason. Go with ext4 or xfs.

>ext4 is old
It's still current, no matter how old it is.

I'm one of those folks who use btrfs raid1 and it just werks. I've even done a disk swap succesfully.

>>59536708
>You can fix that by turning off copy-on-write... and thus also losing all of btrfs's nice features
This can be turned off per file/folder, you don't need to disable CoW globally. See chattr +C

Btrfs has some cute gimmicks in transparent compression of files.

CPU-time is plenty, so I'd suggest mounting it with compress=lzo in most use cases.

>>59537823
I use btrfs since three years on gentoo (with compiling in tmp of course) and never heard or seen the cpu load claim you make. It sits on a 60GB SSD and this thing is always 60-70% full. There was a problem with metadata size two years ago but that was fixed at that time as well.
Also, my processor is fubar and sometimes deadlocks the system when I compile more than 3 things with make -j5 at once. With ext4 i had huge problems with this because files not written completely turned irreversible corrupt without backup. Now with btrfs I never had any sort file corruption thanks to copy on write literally saving my ass every week when my processor decides to shut it down.

Also compress=lzo is nice.

>>59538078
>compiling in tmp

>>59536431
Go with XFS. I've been using it on all my computers for the past 8 years and I've never had a problem with it.

Just remember to have /boot as ext2. 1) GRUB can't install to an XFS partition, 2) you don't need journaling on the boot partition.

ZFS is not only more mature and stable, it is simply a better option to use over BTRFS.

>>59538101
faster and less fragment

>>59538111
Didn't XFS have corruption problems on improper shutdown?

>>59538141
do not most have problems with improper shutdown?

>>59536431
btrfs is kind of shit desu
I would not consider it for any commercial application. If you want to use it at home then go ahead.
btrfs isn't really ready despite people saying it's fine. There are serious bugs that you can get caught in where it will get stuck trying to restripe and there isn't a clear solution.

Source: was involved in a pilot project investigating whether btrfs or ZFS was suitable for long term storage of architecture files

>>59538134
Do you mean /tmp or just mounting /var/tmp as tmpfs?

I think b+ tree based file systems are fundamentally the way things are going, but I'm not sure about the way btrfs and zfs implement their own raid (why is this? I can see arguments for software RAID over hardware, but don't quite get why they don't just use the generic linux one.. It should also be possible to do a generic software RAID that does block hashing).

As for myself, I'm running Reiserfs. Been a few years since it was popular, but it's stable and has been for well over a decade. Plus the code's in maintenance mode, which means things don't keep getting destabilised for new features to be added..

>>59538151
On the file system level, journaling should prevent that. If xfs really has problems with file system corruption, that's terrible and enough reason not to use it.

>>59538151
Any journaled filesystem should recover fine, as long as the disk controller doesn't explicitly write shit to the disk (and if that happens, there's not much an FS can do).

>>59538164
WaifuSlayerFS

>>59538047
Modern CPUs actually compress (with lzo) faster than disks can write, so mounting with compress=lzo turns out to be a performance win in a lot of cases.

Reiser4 supports lzo compression also.

>>59538198
lz4 is better though

File: Capture.png (2KB, 239x134px) Image search: [Google]

2KB, 239x134px

ZFS works.

>>59538191
Can't deny that's part of the fascination. But it really bugs me when good tech gets forgotten due to reasons that have nothing to do with the tech itself. ReiserFS is stable, and serves me well after over a decade. Reiser4 was nearly ready for primetime when the whole murderation business happened. I've run it on test boxes for years and had only minor issues.

Really, Reiser4 still has a number of advantages over btrfs, and just needs a few more people testing it and working out final kinks, but it's not going to get that now, and that makes me a sad panda.

>>59538159
PORTAGE_TMPDIR="/tmp"
/tmp size=80% tmpfs
Something like this for me >>59538078

>>59538151
Copy on write has absolutely no problem with improper shutdown, so go btrfs ;^)

>>59536708
So what about that btrfs "fork" floating around?

Btrfs is pretty nice for PCs, probably the best FS for them. It doesn't need filesystem check. Just symlink fsck.btrfs to yes. I've been using it for years. Snapshots are the best. Want to try something, just do it and revert back.

Raid1 works nice too.

>>59538358
why would you symlink anything to yes
you should symlink it to true

>>59538365
My bad, thanks for correcting.

>>59538240
Copy on write does nothing in the case where a power failure causes the disk controller to write crap.

Suppose your power's failing. Your components will all have different real-minimum voltages to run properly. RAM in particular is quite sensitive, while disks can keep running for a few milliseconds due to their momentum..

So then you have instances when the disk's executing a write command from memory which has already turned into corrupted mush.

Neither Journal not copy on write FSes save you from this. Only a full FS check or hash checking can help you there.

>>59537823
>Go with ext4 or xfs.
DO NOT go with xfs.

Any hard resets (which you'll inevitably do on a desktop usage due to stupid drivers, especially GPU ones) will result in basically the whole thing corrupting because XFS was designed to be run on server hardware with UPS's.

There's been so many times I've been greeted with the fucking horrifying "Superblock not found!" error after anything other than a clean reboot.

>>59538408
Good thing fsck.btrfs is a thing then :^)

>>59538429
Yeah XFS is bad with this. It can't handle the slightest system crash or sudden power loss. The whole thing gets trashed.

>>59536431
Is it beneficial to learn any of this *FS stuff? I mean, from a personal laptop sort of thing and not a server or special purpose computer thing.

I always just used ext4 because that's what all the tutorials use, but I also wondered why they never explain the other options. And when I try to look it up, I never see anything beginner friendly. They all use terms like RAID and LVM and shit.

>>59538978
ext4's perfectly fine for laptop use.

RAID = schemes where multiple drives are used so that you can lose one drive and not lose your data with it.
LVM = Logical Volume Manager - ability to resize partitions easier than if you were going straight to the disk.

>>59539140
>laptop use
I would rather use something that doesn't shit its bed when the power gets cut off or the laptop overheats, like btrfs for example :^)

>>59536431
BTRFS is slow as fuck for certain workloads, I would not use it to store large files or in any scenario that requires high IO workloads.

>>59538429
I never had such problems with XFS.

>>59536431
I've used btrfs for the last year and a half or so, I can't recommend it. I've had quite a few issues with it: snapper hogging space, write power saving causing data corruption (fixed now), remaining space isn't being reported correctly. Just use XFS or EXT4.