Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] btrfs



Rich Pieri <richard.pieri at gmail.com> writes:

> On Fri, 22 Feb 2013 10:04:24 -0500
> Jerry Feldman <gaf at blu.org> wrote:
>
>> Most of the examples I have seen are to install btrfs on raw drives.
>
> Btrfs is, like ZFS, both file system and volume manager. There is
> typically no benefit to not allowing Btrfs to manage entire devices
> unless you need to have part of the disk not be Btrfs. Not allowing
> Btrfs to manage whole devices makes it more difficult to replace
> faulted devices.

    One of the big reason to stick to standard partitioning is that it's
cost is minimal, and not everything in the world groks zfs/btrfs enough
to say "this disk appears to be in use".  I have been forced to attach a
zfs disk to windows before, which correctly noted that the disk had data
on it.  When that very same disk was warranty replaced, asking the
native OS paritioning to copy the label to the new drive was straight
forward.

    zfs on solaris had a particular performance'ism that encouraged you
to use the entire disk, without partitioning, but that was specific to
solaris.  I think it was something with disabling the hardware disk
cache out of paranoia, but I've only touched zfs on solaris a couple of
times, so the memory is a bit fuzzy.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org