On May 7, 2019, at 8:25 PM, Michelle Sullivan <miche...@sorbs.net> wrote:
Paul Mather wrote:
On May 7, 2019, at 1:02 AM, Michelle Sullivan <miche...@sorbs.net> wrote:
[[...]]
Umm.. well I install by memory stick images and I had a 10.2 and an  
11.0 both of which had root on zfs as the default.. I had to manually  
change them.  I haven’t looked at anything later... so did something  
change?  Am I in cloud cookoo land?

I don't know about that, but you may well be misremembering. I just pulled down the 10.2 and 11.0 installers from http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases and in both cases the choices listed in the "Partitioning" step are the same as in the current 12.0 installer: "Auto (UFS) Guided Disk Setup" is listed first and selected by default. "Auto (ZFS) Guided Root-on-ZFS" is listed last (you have to skip past other options such as manually partitioning by hand to select it).
I'm confident in saying that ZFS is (or was) not the default  
partitioning option in either 10.2 or 11.0 as officially released by  
FreeBSD.
Did you use a custom installer you made yourself when installing 10.2 or  
11.0?
it was an emergency USB stick.. so downloaded straight from the website.

My process is boot, select "manual" (so I can set single partition and a swap partition as historically it's done other things) select the whole disk and create partition - this is where I saw it... 'freebsd-zfs' as the default. Second 'create' defaults to 'freebsd-swap' which is always correct. Interestingly the -CURRENT installer just says, "freebsd" and not either -ufs or -zfs ... what ever that defaults to I don't know.

I still fail to see from where you are getting the ZFS default idea. Using the 10.2 installer, for example, when you select "Manual" partitioning, and click through the defaults, the "Type" you are offered when creating the first file system is "freebsd-ufs". If you want to edit that, the help text says "Filesystem type (e.g. freebsd-ufs, freebsd-zfs, freebsd-swap)" (i.e., freebsd-ufs is listed preferentially to freebsd-zfs).
That is all aside from the fact that by choosing to skip past the default  
"Auto (UFS)  Guided Disk Setup" and choose "Manual      Manual Disk Setup  
(experts)" you are choosing an option that assumes you are an "expert" and  
thus are knowledgeable and responsible for the choices you make, whatever  
the subsequent menus may offer.
Again, I suggest there's no basis for the allegation that it's bad that  
FreeBSD is defaulting to ZFS because that is NOT what it's doing (and I'm  
unaware of any plans for 13 to do so).

I don't see how any of this leads to the conclusion that ZFS is "dangerous" to use as a file system.
For me 'dangerous' threshold is when it comes to 'all or nothing'. UFS -  
even when trashed (and I might add I've never had it completely trashed  
on a production image) there are tools to recover what is left of the  
data.  There are no such tools for zfs (barring the one I'm about to test  
- which will be interesting to see if it works... but even then,  
installing windows to recover freebsd :D )
You're saying that ZFS is dangerous because it has no tools for  
catastrophic data recovery... other than the one you are in the process of  
trying to use, and the ones that others on this thread have suggested to  
you. :-\
I'm having a hard time grappling with this logic.


What I believe is dangerous is relying on a post-mortem crash data recovery methodology as a substitute for a backup strategy for data that, in hindsight, is considered important enough to keep. No matter how resilient ZFS or UFS may be, they are no substitute for backups when it comes to data you care about. (File system resiliency will not protect you, e.g., from Ransomware or other malicious or accidental acts of data destruction.)
True, but nothing is perfect, even  backups (how many times have we seen  
or heard of stories when Backups didn't actually work - and the problem  
was only identified when trying to recover from a problem?)
This is the nature of disaster recovery and continuity planning.  The  
solutions adopted are individualistic and are commensurate with the  
anticipated risk/loss.  I agree that backups are themselves subject to risk  
that must be managed.  Yet I don't consider backups "dangerous".
I don't know what the outcome of your risk assessment was and what you  
determined to be your RPO and RTO for disaster recovery so I can't comment  
whether it was realistic or not.  Whatever you chose was based on your  
situation, not mine, and it is a choice you have to live with.  (Bear in  
mind that "not to decide is to decide.")

My situation has been made worse by the fact I was reorganising everything when it went down - so my backups (of the important stuff) were not there and that was a direct consequence of me throwing caution to the wind years before and stopping keeping the full mirror of the data...

I guess, at the time, "throwing caution to the wind" was a risk you were prepared to take (as well as accepting the consequences).

 due to lack of space.  Interestingly have had another drive die in the array - 
and it doesn't just have one or two sectors down it has a *lot* - which was not 
noticed by the original machine - I moved the drive to a byte copier which is 
where it's reporting 100's of sectors damaged... could this be compounded by 
zfs/mfi driver/hba not picking up errors like it should?

Did you have regular pool scrubs enabled? It would have picked up silent data corruption like this. It does for me.
Cheers,

Paul.

_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to