4 ms·

I chose PC-BSD because i had a bad data loss and wanted something more reliable. ZFS on FreeBSD is very mature and stable and PC-BSD provided nice desktop integ

by nec4b 10y ago

I chose PC-BSD because i had a bad data loss and wanted something more reliable. ZFS on FreeBSD is very mature and stable and PC-BSD provided nice desktop integration. For stuff I couldn't do on PC-BSD I used Windows virtual machine. I don't have anything against Linux. But last I read, ZFS on Linux is not native and integrated into the system as well as on PC-BSD. I was thinking more along the line of building a small NAS/FreeBSD server for storage and just install Windows on the main PC as it has always worked pretty well for me and other household memebers are more used to it as well. I will also give OpenSuse a try in a VM to see how it works.

onli 10y ago
Just a +1 for trying out Linux here. Sounds like you'd really like it. ZFS is native by now, https://launchpad.net/~zfs-native/+archive/ubuntu/stable https://launchpad.net/~zfs-native/+archive/ubuntu/stable, though I'm not 100% sure about the current state of the FS in the linux world. Last I read was Ubuntu integrating it by default.
- X86BSD 10y ago
  I would not use ZFS on Linux when it's much more stable and supported better on illumos or FreeBSD.
  - drewg123 10y ago
    I've run ZFS on FreeBSD, Linux and Solaris/Illuminos. The only ZFS issues I've had have been on FreeBSD, when using a zvol for a VM, when GEOM started helpfully automatically resizing the volume causing disk corruption. Eg: GEOM_PART: zvol/tank/vm1 was automatically resized. Use `gpart commit zvol/tank/vm1` to save changes or `gpart undo zvol/tank/vm1` to revert them. Every time I'd run the VM, I'd start seeing ZFS corruption. I finally just moved the VM to a normal file. Sigh. Luckily ZFS was able to recover from the corruption.
  - rleigh 10y ago
    Not sure why this was downvoted when it's objectively true. The Linux ZFS support is functional, but lacking. It's missing NFSv4 ACL support. It's missing per-dataset user and group permissions, forcing all operations to require root privs; on the other systems, the ZFS tools work for all users, with appropriate checks. No delegation of privileges e.g. to allow users to perform admin actions like snapshotting, send/recv. No transparent NFS export. It behaved badly when a disc glitched, requiring a reboot to resolve; the tools started getting stuck in D state when trying to investigate the fault. And just a few weeks ago it refused to mount all my datasets until I changed the mountpoint (for no discernable reason). FreeBSD and IllumOS provide a more mature, well integrated implementation.
baldfat 10y ago
I still fail to see the benefit for a desktop user with ZFS or BTRFS. I find that backing up policy of 2 copies local and one off site (I use CrashPlan) is a very robust system that saves any data loss. My main data loss comes from hardware problems or a command problem like mv photo.jpg and forget the don't over wirte command. That's a simple fix on my side. I copy the effected file over.
- K0SM0S 10y ago
  I can only speak for myself, but here's the gist of it. (Not an expert in this field so please bear with me if I'm too fuzzy or not rigorous enough). - COW[0] + snapshotting[1] basically give you git-like rollback/failsafe capability. You could e.g. trigger it manually before updating or tweaking stuff, or have it automated everytime you run some pacman/apt/yast/whatever. - subvolumes[2] give you the features of partitioning without the physical/ordering limitations (each subvol can expand into free space, etc.) Combined with snapshots (you can snapshop each subvol discretely as its own fs), especially towards another physical btrfs drive, and some automation tool (like Snapper from openSUSE or simply crons), your 'machine-wide git' becomes an effective backup solution (1st order at least but you can snapshot to several machines including off-site obviously). So it's a "set it up and forget it" very powerful filesystem base for your machine, regardless of what you do with it. Rollback instantly, automated backups, self-healing in case of corruption, and btrfs in single-disk or RAID 0/1/10 is incredibly performant. It basically allows you to utterly destroy your install and get it back up and running within minutes (if your snapshotting strategy is well devised, it can be as painless as a matter of changing the boot drive and fixing a single UUID entry in the /boot files, literally 5 minutes). Note: on your root drive, on OS install you'd typically subvol /home, /var, /var/log (so as to debug externally), or domain folders like /var/www and so on and so forth. It basically makes most 'nix fs architectures constrain-free of most physical drive limitations. [0]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_on_Write_.28CoW.29 https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_o... [1]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapshots https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapsh... [2]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvol...
keithpeter 10y ago
I can't speak to filing systems as my approach is to backup often and promiscuously as I trust none of them. I suspect that you might find Slackware a congenial Linux to try. AlienBob produces a live iso for evaluation. http://bear.alienbase.nl/mirrors/slackware-live/latest/ http://bear.alienbase.nl/mirrors/slackware-live/latest/ slackware64-live-current.iso is the one you want to try. KDE 4.14.10

by nec4b 10y ago

onli 10y ago

Just a +1 for trying out Linux here. Sounds like you'd really like it. ZFS is native by now, https://launchpad.net/~zfs-native/+archive/ubuntu/stable https://launchpad.net/~zfs-native/+archive/ubuntu/stable, though I'm not 100% sure about the current state of the FS in the linux world. Last I read was Ubuntu integrating it by default.

X86BSD 10y ago
I would not use ZFS on Linux when it's much more stable and supported better on illumos or FreeBSD.
- drewg123 10y ago
  I've run ZFS on FreeBSD, Linux and Solaris/Illuminos. The only ZFS issues I've had have been on FreeBSD, when using a zvol for a VM, when GEOM started helpfully automatically resizing the volume causing disk corruption. Eg: GEOM_PART: zvol/tank/vm1 was automatically resized. Use `gpart commit zvol/tank/vm1` to save changes or `gpart undo zvol/tank/vm1` to revert them. Every time I'd run the VM, I'd start seeing ZFS corruption. I finally just moved the VM to a normal file. Sigh. Luckily ZFS was able to recover from the corruption.
- rleigh 10y ago
  Not sure why this was downvoted when it's objectively true. The Linux ZFS support is functional, but lacking. It's missing NFSv4 ACL support. It's missing per-dataset user and group permissions, forcing all operations to require root privs; on the other systems, the ZFS tools work for all users, with appropriate checks. No delegation of privileges e.g. to allow users to perform admin actions like snapshotting, send/recv. No transparent NFS export. It behaved badly when a disc glitched, requiring a reboot to resolve; the tools started getting stuck in D state when trying to investigate the fault. And just a few weeks ago it refused to mount all my datasets until I changed the mountpoint (for no discernable reason). FreeBSD and IllumOS provide a more mature, well integrated implementation.

baldfat 10y ago

I still fail to see the benefit for a desktop user with ZFS or BTRFS. I find that backing up policy of 2 copies local and one off site (I use CrashPlan) is a very robust system that saves any data loss. My main data loss comes from hardware problems or a command problem like mv photo.jpg and forget the don't over wirte command. That's a simple fix on my side. I copy the effected file over.

K0SM0S 10y ago
I can only speak for myself, but here's the gist of it. (Not an expert in this field so please bear with me if I'm too fuzzy or not rigorous enough). - COW[0] + snapshotting[1] basically give you git-like rollback/failsafe capability. You could e.g. trigger it manually before updating or tweaking stuff, or have it automated everytime you run some pacman/apt/yast/whatever. - subvolumes[2] give you the features of partitioning without the physical/ordering limitations (each subvol can expand into free space, etc.) Combined with snapshots (you can snapshop each subvol discretely as its own fs), especially towards another physical btrfs drive, and some automation tool (like Snapper from openSUSE or simply crons), your 'machine-wide git' becomes an effective backup solution (1st order at least but you can snapshot to several machines including off-site obviously). So it's a "set it up and forget it" very powerful filesystem base for your machine, regardless of what you do with it. Rollback instantly, automated backups, self-healing in case of corruption, and btrfs in single-disk or RAID 0/1/10 is incredibly performant. It basically allows you to utterly destroy your install and get it back up and running within minutes (if your snapshotting strategy is well devised, it can be as painless as a matter of changing the boot drive and fixing a single UUID entry in the /boot files, literally 5 minutes). Note: on your root drive, on OS install you'd typically subvol /home, /var, /var/log (so as to debug externally), or domain folders like /var/www and so on and so forth. It basically makes most 'nix fs architectures constrain-free of most physical drive limitations. [0]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_on_Write_.28CoW.29 https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Copy_o... [1]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapshots https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Snapsh... [2]: https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvolumes https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Subvol...

keithpeter 10y ago

I can't speak to filing systems as my approach is to backup often and promiscuously as I trust none of them. I suspect that you might find Slackware a congenial Linux to try. AlienBob produces a live iso for evaluation. http://bear.alienbase.nl/mirrors/slackware-live/latest/ http://bear.alienbase.nl/mirrors/slackware-live/latest/ slackware64-live-current.iso is the one you want to try. KDE 4.14.10