On Wed, Apr 27, 2016 at 2:18 PM, Juan Alberto Cirez
<jaci...@rdcsafety.com> wrote:
> Quick question: Supposed I have n-number of storage pods (physical
> servers with n-number of physical hhds). The end deployment will be
> btrfs at the brick/block level with a distributed file system on top.
> Keeping in mind that my overriding goal is to have high availability
> and the mechanism whereby the lost of a drive or multiple drives in a
> single pod will not jeopardize data.
> Does partitioning the physical drives and creating btrfs filesystem on
> each partition, then configuring each partition as individual
> bricks/blocks offer ANY added benefits over grouping the entire pod
> into a drive pool and using that pool as a single block/brick to
> expose to the distributed filesystem?


Distros typically have libblkid, so 'blkid' command will show you
Btrfs is on the drive regardless of partitioning. If the drive might
ever see Windows or OS X, then a partition will tell those OS's the
drive isn't empty, as they will not recognize Btrfs, but will see the

Since you mention HA, you need to use something other than Btrfs only.
The device failure notification right now is slim to none with Btrfs,
it's limited really to just kernel messages. So you should looking at
hardware raid, or mdadm, or LVM raid, plus XFS. While XFS does not
offer data checksumming or snapshotting it does offer metadata
checksums in the most recent V5 metadata format.

And then there's this (admittedly rather conservative) disclaimer:
"Btrfs is under heavy development, and is not suitable for any uses
other than benchmarking and review."

I include that just to point out you probably shouldn't put all eggs
in one basket.

For Btrfs, mdadm, or lvm raid, you need to make sure that the SCSI
command timer (a kernel setting per block device) is longer than the
drive's SCT ERC setting.

cat /sys/block/<dev>/device/timeout
smartctl -l scterc <dev>

If the command timer is shorter, bad sectors will not get reported as
read errors for proper fixup, instead there will be a link reset and
it's just inevitable there will be worse problems.

Chris Murphy
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to