Live data from Hacker News

Rockstor, a Linux and BTRFS Based NAS Solution

rockstor.com

51–52 of 52 posts

Re: Rockstor, a Linux and BTRFS Based NAS Solution

#51
post #49

Earlier quoted context omitted.

If you don't already, I strongly recommend lurking on the btrfs mailing list. There are regular fixes to balancing, ENOSPC, send/receive and the btrfs-progs tools; occasional questions and fixes related to the compression code. Be prepared to update your kernels and tools often and independent of your vendor. Btrfs-progs will likely need to come from the git repo, so building your own packages for distribution around…

Oh my god. The debate was between ZFS and btrfs and although I favored ZFS, the extra kernel module and the upcoming support in distros led to the decision for btrfs. However we won't do anything fancy with it. Basically just using the whole disk for a distributed filesystem without snapshots and we use btrfs because of checksumming and scrubbing weekly/monthly to detect corrupt disks and data and maybe compression w…

I wouldn't use ZoL either -- I read that mailing list for quite awhile too, and skimmed most of the issues on GitHub. As of about six months ago, lockups were too frequent for my taste. All the implementations are improving though and the OpenZFS movement is promising. A caution here too: if you use ZFS, all implementations are not equal, you'll need to research the specifics for each platform on which you intend to use it; and the compatibility [with other implementations] if you want to move the file system [to a different platform]. If I was rolling out ZFS, I'd only use it on Illumos/OpenIndiana (vs., say ZoL).

I have been waiting and watching for a long time for most of these "new" filesystem features (pools, fs-level RAID, checksums, send/receive), but I am a "filesystem conservative" (especially in production; less so on my own machines) -- I'll keep waiting awhile longer. On production Linux today, I stay with EXT4 or XFS.

Re: Rockstor, a Linux and BTRFS Based NAS Solution

#52
post #20

Earlier quoted context omitted.

Where did you get your hilarious "data loss on attempting to re-silver a 3TB mirror is 1 in 5" statistic from?

The non-recoverable bit error rate spec. NetApp tracks it with their Nearstore product line which used SATA drives in a NAS box (they have been for a while actually, when I left they had data on about 65 million drive hours) and while Seagate quotes it a 1x10^15 bits but its actually closer to 5 in 10^15 bits. A 3TB drive has 3x10^13 bits of data (closer to 3x10^14 when you account for track markers and error recover…

So every time you do a zfs scrub on a large pool (many TB) you should see errors that are detected and corrected.

But you don't...

Post reply on HN