another ZFS (on OSX) success story
68 views
Skip to first unread message
Dave Cottlehuber
Nov 11, 2014, 3:27:31 PM11/11/14
to zfs-...@googlegroups.com
Hey folks,
It’s always useful to be able to point new users to how zfs benefits them, so here’s another one, both the flexibility of datasets, as well as relying on zpool scrub to ensure data integrity.
About 2 weeks ago, my laptop blew up its GPU (6th time this year) so it was in for repair. This happens so often, I just switch to the nearest other machine and grab my latest replicated datasets for whatever project I’m working on while they repair it.
However after a few strange clicks starting on Sunday, that 2nd machine started to have problems too. It failed to boot from OSX sometimes, and eventually I could only get it to work from internet recovery boot. Such fun. I was able to confirm my data was OK, by running zpool scrub again after booting via FreeBSD — mfsBSD[1] is excellent for this. Of course, I had no way of knowing if the HFS+ partition used for OSX itself, was corrupt or not, nor knowing if the time machine backups also had silent corruption. Apple’s disk repair didn’t report any issues, but a 3rd party smart utility showed a high, and increasing, rate of failed sectors and unrecoverable reads. OSX still wouldn’t boot, so I booted up FreeBSD and did a final ‘zfs send’ to my remote server.
I co-opted a netbook from a friend, and continued working over ssh for the rest of the day, while my main hardware was in for repair. replicated zfs datasets FTW again.
Once the laptop hardware was repaired, recovery was as simple as pulling back the newer snapshots from the FreeBSD server, and I was back up and running in minutes. I spent more time organising the repairs than managing data recovery.
So many many thanks to lundman, brendon, ilovezfs, Björn and others for keeping this ship up and running over the years.
A+, Dave
— sent from my Couch
[1]: http://mfsbsd.vx.sk/
[2]: my setup
— running very recent zfsonosx builds from source
Feb 2011 MacBook Pro 15”, dual SSD, 16GB RAM
Jan 2013 iMac 27”, 3TB disk, 32GB RAM
— FreeBSD 10.1-BETA3-p1 (living on the edge)
FreeBSD 8 core server, 3TB disks, mirrored zpool, 32GB ECC RAM
It’s always useful to be able to point new users to how zfs benefits them, so here’s another one, both the flexibility of datasets, as well as relying on zpool scrub to ensure data integrity.
About 2 weeks ago, my laptop blew up its GPU (6th time this year) so it was in for repair. This happens so often, I just switch to the nearest other machine and grab my latest replicated datasets for whatever project I’m working on while they repair it.
However after a few strange clicks starting on Sunday, that 2nd machine started to have problems too. It failed to boot from OSX sometimes, and eventually I could only get it to work from internet recovery boot. Such fun. I was able to confirm my data was OK, by running zpool scrub again after booting via FreeBSD — mfsBSD[1] is excellent for this. Of course, I had no way of knowing if the HFS+ partition used for OSX itself, was corrupt or not, nor knowing if the time machine backups also had silent corruption. Apple’s disk repair didn’t report any issues, but a 3rd party smart utility showed a high, and increasing, rate of failed sectors and unrecoverable reads. OSX still wouldn’t boot, so I booted up FreeBSD and did a final ‘zfs send’ to my remote server.
I co-opted a netbook from a friend, and continued working over ssh for the rest of the day, while my main hardware was in for repair. replicated zfs datasets FTW again.
Once the laptop hardware was repaired, recovery was as simple as pulling back the newer snapshots from the FreeBSD server, and I was back up and running in minutes. I spent more time organising the repairs than managing data recovery.
So many many thanks to lundman, brendon, ilovezfs, Björn and others for keeping this ship up and running over the years.
A+, Dave
— sent from my Couch
[1]: http://mfsbsd.vx.sk/
[2]: my setup
— running very recent zfsonosx builds from source
Feb 2011 MacBook Pro 15”, dual SSD, 16GB RAM
Jan 2013 iMac 27”, 3TB disk, 32GB RAM
— FreeBSD 10.1-BETA3-p1 (living on the edge)
FreeBSD 8 core server, 3TB disks, mirrored zpool, 32GB ECC RAM
BelecMartin
Nov 11, 2014, 3:32:57 PM11/11/14
to zfs-...@googlegroups.com
Yeah!
Jason Belec
Sent from my "It's an iPod, a Phone, and an Internet Device..."
> --
>
> ---
> You received this message because you are subscribed to the Google Groups "zfs-macos" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to zfs-macos+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Jason Belec
Sent from my "It's an iPod, a Phone, and an Internet Device..."
>
> ---
> You received this message because you are subscribed to the Google Groups "zfs-macos" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to zfs-macos+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Alex Blewitt
Nov 11, 2014, 3:49:16 PM11/11/14
to zfs-...@googlegroups.com
On 11 Nov 2014, at 20:27, Dave Cottlehuber <d...@jsonified.com> wrote:
> Hey folks,
>
> It’s always useful to be able to point new users to how zfs benefits them, so here’s another one, both the flexibility of datasets, as well as relying on zpool scrub to ensure data integrity.
>
> About 2 weeks ago, my laptop blew up its GPU (6th time this year) so it was in for repair. This happens so often, I just switch to the nearest other machine and grab my latest replicated datasets for whatever project I’m working on while they repair it.
>
> However after a few strange clicks starting on Sunday, that 2nd machine started to have problems too. It failed to boot from OSX sometimes, and eventually I could only get it to work from internet recovery boot. Such fun. I was able to confirm my data was OK, by running zpool scrub again after booting via FreeBSD — mfsBSD[1] is excellent for this. Of course, I had no way of knowing if the HFS+ partition used for OSX itself, was corrupt or not, nor knowing if the time machine backups also had silent corruption. Apple’s disk repair didn’t report any issues, but a 3rd party smart utility showed a high, and increasing, rate of failed sectors and unrecoverable reads. OSX still wouldn’t boot, so I booted up FreeBSD and did a final ‘zfs send’ to my remote server.
>
> I co-opted a netbook from a friend, and continued working over ssh for the rest of the day, while my main hardware was in for repair. replicated zfs datasets FTW again.
>
> Once the laptop hardware was repaired, recovery was as simple as pulling back the newer snapshots from the FreeBSD server, and I was back up and running in minutes. I spent more time organising the repairs than managing data recovery.
Great news :)
> Hey folks,
>
> It’s always useful to be able to point new users to how zfs benefits them, so here’s another one, both the flexibility of datasets, as well as relying on zpool scrub to ensure data integrity.
>
> About 2 weeks ago, my laptop blew up its GPU (6th time this year) so it was in for repair. This happens so often, I just switch to the nearest other machine and grab my latest replicated datasets for whatever project I’m working on while they repair it.
>
> However after a few strange clicks starting on Sunday, that 2nd machine started to have problems too. It failed to boot from OSX sometimes, and eventually I could only get it to work from internet recovery boot. Such fun. I was able to confirm my data was OK, by running zpool scrub again after booting via FreeBSD — mfsBSD[1] is excellent for this. Of course, I had no way of knowing if the HFS+ partition used for OSX itself, was corrupt or not, nor knowing if the time machine backups also had silent corruption. Apple’s disk repair didn’t report any issues, but a 3rd party smart utility showed a high, and increasing, rate of failed sectors and unrecoverable reads. OSX still wouldn’t boot, so I booted up FreeBSD and did a final ‘zfs send’ to my remote server.
>
> I co-opted a netbook from a friend, and continued working over ssh for the rest of the day, while my main hardware was in for repair. replicated zfs datasets FTW again.
>
> Once the laptop hardware was repaired, recovery was as simple as pulling back the newer snapshots from the FreeBSD server, and I was back up and running in minutes. I spent more time organising the repairs than managing data recovery.
> So many many thanks to lundman, brendon, ilovezfs, Björn and others for keeping this ship up and running over the years.
Alex
Reply all
Reply to author
Forward
0 new messages