wow, talk about a knee jerk reaction...
On Jul 31, 2009, at 3:23 PM, Dave Stubbs wrote:
I don't mean to be offensive Russel, but if you do
ever return to ZFS, please promise me that you will
never, ever, EVER run it virtualized on top of NTFS
(a.k.a. worst file system ever) in a production
environment. Microsoft Windows is a horribly
unreliable operating system in situations where
things like protecting against data corruption are
important. Microsoft knows this
Oh WOW! Whether or not our friend Russel virtualized on top of NTFS
(he didn't - he used raw disk access) this point is amazing!
This point doesn't matter. VB sits between the guest OS and the raw
disk and
drops cache flush requests.
System5 - based on this thread I'd say you can't really make this
claim at all. Solaris suffered a crash and the ZFS filesystem lost
EVERYTHING! And there aren't even any recovery tools?
As has been described many times over the past few years, there is a
manual
procedure.
HANG YOUR HEADS!!!
Recovery from the same situation is EASY on NTFS. There are piles
of tools out there that will recover the file system, and failing
that, locate and extract data. The key parts of the file system are
stored in multiple locations on the disk just in case. It's been
this way for over 10 years.
ZFS also has redundant metadata written at different places on the disk.
ZFS, like NTFS, issues cache flush requests with the expectation that
the disk honors that request.
I'd say it seems from this thread that my data is a lot safer on
NTFS than it is on ZFS!
Nope. NTFS doesn't know when data is corrupted. Until it does, it is
blissfully ignorant.
I can't believe my eyes as I read all these responses blaming system
engineering and hiding behind ECC memory excuses and "well, you
know, ZFS is intended for more Professional systems and not consumer
devices, etc etc." My goodness! You DO realize that Sun has this
website called opensolaris.org which actually proposes to have
people use ZFS on commodity hardware, don't you? I don't see a huge
warning on that site saying "ATTENTION: YOU PROBABLY WILL LOSE ALL
YOUR DATA".
You probably won't lose all of your data. Statistically speaking, there
are very few people who have seen this. There are many more cases
where ZFS detected and repaired corruption.
I recently flirted with putting several large Unified Storage 7000
systems on our corporate network. The hype about ZFS is quite
compelling and I had positive experience in my lab setting. But
because of not having Solaris capability on our staff we went in
another direction instead.
Interesting. The 7000 systems completely shield you from the underlying
OS. You administer the system via a web browser interface. There is no
OS to learn with these systems, just like you don't go around requiring
Darwin knowledge to use your iPhone.
Reading this thread, I'm SO glad we didn't put ZFS in production in
ANY way. Guys, this is the real world. Stuff happens. It doesn't
matter what the reason is - hardware lying about cache commits, out-
of-order commits, failure to use ECC memory, whatever. It is
ABSOLUTELY unacceptable for the filesystem to be entirely lost. No
excuse or rationalization of any type can be justified. There MUST
be at least the base suite of tools to deal with this stuff.
without it, ZFS simply isn't ready yet.
At the risk of being redundant, redundant there is a procedure.
The fine folks at Sun, like Victor Latushkin, have helped people recover
such pools, as has been pointed out in this thread several times.
This is not the sort of procedure easily done over an open forum, it is
more efficient to recover via a service call.
Microsoft talks about NTFS in Windows 2008[*] as, "Self-healing NTFS
preserves as much data as possible, based on the type of corruption
detected." Regarding catastrophic failures they note, "Self-healing
NTFS accepts the mount request, but if the volume is known to have
some form of corruption, a repair is initiated immediately. The
exception
to this would be a catastrophic failure that requires an offline
recovery
method—such as manual recovery—to minimize the loss of data."
Do you consider that any different than the current state of ZFS?
[*] http://technet.microsoft.com/en-us/library/cc771388(WS.10).aspx
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
