Discussion:
OpenZFS
(too old to reply)
Gordan Bobic
2013-09-20 09:20:35 UTC
Permalink
I cannot help but feel it would be quite awesome if ZFS-fuse were a part of
this:

http://open-zfs.org/wiki/Main_Page
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
ray vantassle
2013-09-20 13:35:12 UTC
Permalink
It would also be great if it worked (reliably!!) an a typical home computer
with around 2GB of ram. Not everybody has 64GB of ram. Great if it worked
on a 32 bit OS, too.


FWIW, I have ZFS-FUSE running on a pogoplug. 256MB RAM ARM cpu. Not
anything fancy, just a single disk zfs fs. I wanted ZFS for the checksum
feature.
Post by Gordan Bobic
I cannot help but feel it would be quite awesome if ZFS-fuse were a part
http://open-zfs.org/wiki/Main_Page
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Emmanuel Anne
2013-09-20 14:57:34 UTC
Permalink
About the checksum feature, I have read lately that if you don't have ecc
ram then it's adviced NOT to run any scrub, because you increase the
chances to destroy the pool when nothing is actually wrong (but just
because a bit of the ram changed at the wrong time).
I had this false positive once, and it was only about a single file, but
it's very annoying, and I am not even sure I had run any scrub at that
time. So in a nutshell, without ecc ram, these checksums can do more bad
than good.
It was in the comments about the creation of the open-zfs site on slashdot.
Post by ray vantassle
It would also be great if it worked (reliably!!) an a typical home
computer with around 2GB of ram. Not everybody has 64GB of ram. Great if
it worked on a 32 bit OS, too.
FWIW, I have ZFS-FUSE running on a pogoplug. 256MB RAM ARM cpu. Not
anything fancy, just a single disk zfs fs. I wanted ZFS for the checksum
feature.
Post by Gordan Bobic
I cannot help but feel it would be quite awesome if ZFS-fuse were a part
http://open-zfs.org/wiki/Main_Page
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups
"zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
my zfs-fuse git repository :
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Emmanuel Anne
2013-09-20 14:59:43 UTC
Permalink
And Gordon, without any active developpement going on zfs-fuse now,it
wouldn't make much sense to add it to this page, but maybe you can add a
link somewhere to show it still exists and has its uses though...
Post by Emmanuel Anne
About the checksum feature, I have read lately that if you don't have ecc
ram then it's adviced NOT to run any scrub, because you increase the
chances to destroy the pool when nothing is actually wrong (but just
because a bit of the ram changed at the wrong time).
I had this false positive once, and it was only about a single file, but
it's very annoying, and I am not even sure I had run any scrub at that
time. So in a nutshell, without ecc ram, these checksums can do more bad
than good.
It was in the comments about the creation of the open-zfs site on slashdot.
Post by ray vantassle
It would also be great if it worked (reliably!!) an a typical home
computer with around 2GB of ram. Not everybody has 64GB of ram. Great if
it worked on a 32 bit OS, too.
FWIW, I have ZFS-FUSE running on a pogoplug. 256MB RAM ARM cpu. Not
anything fancy, just a single disk zfs fs. I wanted ZFS for the checksum
feature.
Post by Gordan Bobic
I cannot help but feel it would be quite awesome if ZFS-fuse were a part
http://open-zfs.org/wiki/Main_Page
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups
"zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
my zfs-fuse git repository :
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Gordan Bobic
2013-09-20 15:42:03 UTC
Permalink
Perhaps an interested party can be found to maintain zfs-fuse. It still has
it's uses, and in some cases (e.g. 32-bit or small-memory Linux systems) it
is still the only viable option.
Post by Emmanuel Anne
And Gordon, without any active developpement going on zfs-fuse now,it
wouldn't make much sense to add it to this page, but maybe you can add a
link somewhere to show it still exists and has its uses though...
Post by Emmanuel Anne
About the checksum feature, I have read lately that if you don't have ecc
ram then it's adviced NOT to run any scrub, because you increase the
chances to destroy the pool when nothing is actually wrong (but just
because a bit of the ram changed at the wrong time).
I had this false positive once, and it was only about a single file, but
it's very annoying, and I am not even sure I had run any scrub at that
time. So in a nutshell, without ecc ram, these checksums can do more bad
than good.
It was in the comments about the creation of the open-zfs site on slashdot.
Post by ray vantassle
It would also be great if it worked (reliably!!) an a typical home
computer with around 2GB of ram. Not everybody has 64GB of ram. Great if
it worked on a 32 bit OS, too.
FWIW, I have ZFS-FUSE running on a pogoplug. 256MB RAM ARM cpu. Not
anything fancy, just a single disk zfs fs. I wanted ZFS for the checksum
feature.
Post by Gordan Bobic
I cannot help but feel it would be quite awesome if ZFS-fuse were a
http://open-zfs.org/wiki/Main_Page
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Francois Dion
2013-09-20 16:42:20 UTC
Permalink
Sharing a pool on a multi boot laptop with OpenIndiana and Linux Mint.
zfs-fuse works well for that under mint. I also use zfs-fuse on ARM devices
for the same reason as Gordan.

Francois
Post by Gordan Bobic
Perhaps an interested party can be found to maintain zfs-fuse. It still
has it's uses, and in some cases (e.g. 32-bit or small-memory Linux
systems) it is still the only viable option.
Post by Emmanuel Anne
And Gordon, without any active developpement going on zfs-fuse now,it
wouldn't make much sense to add it to this page, but maybe you can add a
link somewhere to show it still exists and has its uses though...
Post by Emmanuel Anne
About the checksum feature, I have read lately that if you don't have
ecc ram then it's adviced NOT to run any scrub, because you increase the
chances to destroy the pool when nothing is actually wrong (but just
because a bit of the ram changed at the wrong time).
I had this false positive once, and it was only about a single file, but
it's very annoying, and I am not even sure I had run any scrub at that
time. So in a nutshell, without ecc ram, these checksums can do more bad
than good.
It was in the comments about the creation of the open-zfs site on slashdot.
Post by ray vantassle
It would also be great if it worked (reliably!!) an a typical home
computer with around 2GB of ram. Not everybody has 64GB of ram. Great if
it worked on a 32 bit OS, too.
FWIW, I have ZFS-FUSE running on a pogoplug. 256MB RAM ARM cpu. Not
anything fancy, just a single disk zfs fs. I wanted ZFS for the checksum
feature.
Post by Gordan Bobic
I cannot help but feel it would be quite awesome if ZFS-fuse were a
http://open-zfs.org/wiki/Main_Page
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups
"zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Durval Menezes
2013-09-20 16:45:49 UTC
Permalink
Hello folks,

I use zfs-fuse with my recovery system (based on PLD RCD) and it works
well.

Continued work on zfs-fuse would be much appreciated.

Cheers,
--
Durval.
Post by Francois Dion
Sharing a pool on a multi boot laptop with OpenIndiana and Linux Mint.
zfs-fuse works well for that under mint. I also use zfs-fuse on ARM devices
for the same reason as Gordan.
Francois
Post by Gordan Bobic
Perhaps an interested party can be found to maintain zfs-fuse. It still
has it's uses, and in some cases (e.g. 32-bit or small-memory Linux
systems) it is still the only viable option.
Post by Emmanuel Anne
And Gordon, without any active developpement going on zfs-fuse now,it
wouldn't make much sense to add it to this page, but maybe you can add a
link somewhere to show it still exists and has its uses though...
Post by Emmanuel Anne
About the checksum feature, I have read lately that if you don't have
ecc ram then it's adviced NOT to run any scrub, because you increase the
chances to destroy the pool when nothing is actually wrong (but just
because a bit of the ram changed at the wrong time).
I had this false positive once, and it was only about a single file,
but it's very annoying, and I am not even sure I had run any scrub at that
time. So in a nutshell, without ecc ram, these checksums can do more bad
than good.
It was in the comments about the creation of the open-zfs site on slashdot.
Post by ray vantassle
It would also be great if it worked (reliably!!) an a typical home
computer with around 2GB of ram. Not everybody has 64GB of ram. Great if
it worked on a 32 bit OS, too.
FWIW, I have ZFS-FUSE running on a pogoplug. 256MB RAM ARM cpu. Not
anything fancy, just a single disk zfs fs. I wanted ZFS for the checksum
feature.
Post by Gordan Bobic
I cannot help but feel it would be quite awesome if ZFS-fuse were a
http://open-zfs.org/wiki/Main_Page
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it,
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups
"zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Gordan Bobic
2013-09-20 15:38:05 UTC
Permalink
That doesn't entirely make sense. If you have a redundant pool, then a
detected error will cause recovery to be attempted. This involves comparing
the checksum of the block against combinations of data blocks on the disks,
and when the combination that matches is found, the un-matching set is
overwritten to repair it.

This should ensure that unless you have a double error (e.g. in both
metadata AND data), a good working block still gets recovered and
overwritten. If a good block is erroneously replaced with an identical good
block due to a memory error, so be it.

The point being that if the implementation is good and correct, ZFS will
still help even in face of ECC-less RAM erroring out.
Post by Emmanuel Anne
About the checksum feature, I have read lately that if you don't have ecc
ram then it's adviced NOT to run any scrub, because you increase the
chances to destroy the pool when nothing is actually wrong (but just
because a bit of the ram changed at the wrong time).
I had this false positive once, and it was only about a single file, but
it's very annoying, and I am not even sure I had run any scrub at that
time. So in a nutshell, without ecc ram, these checksums can do more bad
than good.
It was in the comments about the creation of the open-zfs site on slashdot.
Post by ray vantassle
It would also be great if it worked (reliably!!) an a typical home
computer with around 2GB of ram. Not everybody has 64GB of ram. Great if
it worked on a 32 bit OS, too.
FWIW, I have ZFS-FUSE running on a pogoplug. 256MB RAM ARM cpu. Not
anything fancy, just a single disk zfs fs. I wanted ZFS for the checksum
feature.
Post by Gordan Bobic
I cannot help but feel it would be quite awesome if ZFS-fuse were a part
http://open-zfs.org/wiki/Main_Page
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups
"zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Durval Menezes
2013-09-20 16:48:40 UTC
Permalink
Hi Folks,

Gordan: I agree with you (not that I condone the use of ECC-less systems,
but when it simply isn't an option as in most notebooks and also embedded
systems, I think things are much better off reliability-wise with ZFS than
with other file systems).

Emmanuel: can you mention any situation where ZFS would corrupt data in an
ECC-less system where another filesystem won't make at least as much (and
possibly much more) mess?

Cheers,
--
Durval.
Post by Gordan Bobic
That doesn't entirely make sense. If you have a redundant pool, then a
detected error will cause recovery to be attempted. This involves comparing
the checksum of the block against combinations of data blocks on the disks,
and when the combination that matches is found, the un-matching set is
overwritten to repair it.
This should ensure that unless you have a double error (e.g. in both
metadata AND data), a good working block still gets recovered and
overwritten. If a good block is erroneously replaced with an identical good
block due to a memory error, so be it.
The point being that if the implementation is good and correct, ZFS will
still help even in face of ECC-less RAM erroring out.
Post by Emmanuel Anne
About the checksum feature, I have read lately that if you don't have ecc
ram then it's adviced NOT to run any scrub, because you increase the
chances to destroy the pool when nothing is actually wrong (but just
because a bit of the ram changed at the wrong time).
I had this false positive once, and it was only about a single file, but
it's very annoying, and I am not even sure I had run any scrub at that
time. So in a nutshell, without ecc ram, these checksums can do more bad
than good.
It was in the comments about the creation of the open-zfs site on slashdot.
Post by ray vantassle
It would also be great if it worked (reliably!!) an a typical home
computer with around 2GB of ram. Not everybody has 64GB of ram. Great if
it worked on a 32 bit OS, too.
FWIW, I have ZFS-FUSE running on a pogoplug. 256MB RAM ARM cpu. Not
anything fancy, just a single disk zfs fs. I wanted ZFS for the checksum
feature.
Post by Gordan Bobic
I cannot help but feel it would be quite awesome if ZFS-fuse were a
http://open-zfs.org/wiki/Main_Page
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups
"zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Emmanuel Anne
2013-09-20 18:41:00 UTC
Permalink
http://hardware.slashdot.org/comments.pl?sid=4226771&cid=44881099

This should point directly to the right comment !
Post by Durval Menezes
Hi Folks,
Gordan: I agree with you (not that I condone the use of ECC-less systems,
but when it simply isn't an option as in most notebooks and also embedded
systems, I think things are much better off reliability-wise with ZFS than
with other file systems).
Emmanuel: can you mention any situation where ZFS would corrupt data in an
ECC-less system where another filesystem won't make at least as much (and
possibly much more) mess?
Cheers,
--
Durval.
Post by Gordan Bobic
That doesn't entirely make sense. If you have a redundant pool, then a
detected error will cause recovery to be attempted. This involves comparing
the checksum of the block against combinations of data blocks on the disks,
and when the combination that matches is found, the un-matching set is
overwritten to repair it.
This should ensure that unless you have a double error (e.g. in both
metadata AND data), a good working block still gets recovered and
overwritten. If a good block is erroneously replaced with an identical good
block due to a memory error, so be it.
The point being that if the implementation is good and correct, ZFS will
still help even in face of ECC-less RAM erroring out.
Post by Emmanuel Anne
About the checksum feature, I have read lately that if you don't have
ecc ram then it's adviced NOT to run any scrub, because you increase the
chances to destroy the pool when nothing is actually wrong (but just
because a bit of the ram changed at the wrong time).
I had this false positive once, and it was only about a single file, but
it's very annoying, and I am not even sure I had run any scrub at that
time. So in a nutshell, without ecc ram, these checksums can do more bad
than good.
It was in the comments about the creation of the open-zfs site on slashdot.
Post by ray vantassle
It would also be great if it worked (reliably!!) an a typical home
computer with around 2GB of ram. Not everybody has 64GB of ram. Great if
it worked on a 32 bit OS, too.
FWIW, I have ZFS-FUSE running on a pogoplug. 256MB RAM ARM cpu. Not
anything fancy, just a single disk zfs fs. I wanted ZFS for the checksum
feature.
Post by Gordan Bobic
I cannot help but feel it would be quite awesome if ZFS-fuse were a
http://open-zfs.org/wiki/Main_Page
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups
"zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
my zfs-fuse git repository :
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Gordan Bobic
2013-09-20 18:59:33 UTC
Permalink
That sounds like a lot of handwaving and hearsay. The point remains that
ZFS' design still makes it more resistant to issues like this than a
traditional file system. I'm happy to be persuaded otherwise, but I'd
need to see a specific case in which a single bit flip will destroy a
ZFS pool and conclusive proof that a single bit flip _cannot_ similarly
destroy a data set on a more traditional storage stack.

If the aim was to show that ZFS can be more risky than a traditional FS,
this falls well short. Especially since I can demonstrate that ZFS has
protected my data from damage due to silent disk corruption a large
number of times already.

Gordan
Post by Emmanuel Anne
http://hardware.slashdot.org/comments.pl?sid=4226771&cid=44881099
This should point directly to the right comment !
Hi Folks,
Gordan: I agree with you (not that I condone the use of ECC-less
systems, but when it simply isn't an option as in most notebooks and
also embedded systems, I think things are much better off
reliability-wise with ZFS than with other file systems).
Emmanuel: can you mention any situation where ZFS would corrupt data
in an ECC-less system where another filesystem won't make at least
as much (and possibly much more) mess?
Cheers,
--
Durval.
On Fri, Sep 20, 2013 at 12:38 PM, Gordan Bobic
That doesn't entirely make sense. If you have a redundant pool,
then a detected error will cause recovery to be attempted. This
involves comparing the checksum of the block against
combinations of data blocks on the disks, and when the
combination that matches is found, the un-matching set is
overwritten to repair it.
This should ensure that unless you have a double error (e.g. in
both metadata AND data), a good working block still gets
recovered and overwritten. If a good block is erroneously
replaced with an identical good block due to a memory error, so
be it.
The point being that if the implementation is good and correct,
ZFS will still help even in face of ECC-less RAM erroring out.
On Fri, Sep 20, 2013 at 3:57 PM, Emmanuel Anne
About the checksum feature, I have read lately that if you
don't have ecc ram then it's adviced NOT to run any scrub,
because you increase the chances to destroy the pool when
nothing is actually wrong (but just because a bit of the ram
changed at the wrong time).
I had this false positive once, and it was only about a
single file, but it's very annoying, and I am not even sure
I had run any scrub at that time. So in a nutshell, without
ecc ram, these checksums can do more bad than good.
It was in the comments about the creation of the open-zfs
site on slashdot.
It would also be great if it worked (reliably!!) an a
typical home computer with around 2GB of ram. Not
everybody has 64GB of ram. Great if it worked on a 32
bit OS, too.
FWIW, I have ZFS-FUSE running on a pogoplug. 256MB RAM
ARM cpu. Not anything fancy, just a single disk zfs fs.
I wanted ZFS for the checksum feature.
On Fri, Sep 20, 2013 at 4:20 AM, Gordan Bobic
I cannot help but feel it would be quite awesome if
http://open-zfs.org/wiki/Main_Page
--
--
To post to this group, send email to
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed
to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
For more options, visit
https://groups.google.com/groups/opt_out.
--
--
To post to this group, send email to
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to
the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to
For more options, visit
https://groups.google.com/groups/opt_out.
--
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To post to this group, send email to
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the
Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to
For more options, visit
https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the
Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it,
For more options, visit https://groups.google.com/groups/opt_out.
--
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Emmanuel Anne
2013-09-20 20:42:06 UTC
Permalink
Well as I already said, I experienced it the bad way, a file which suddenly
became impossible to access, and no sign of failure at all from the disk.
In my case it was a single file, but it was rather tricky to recover it. In
this case, for a single bit, it was a block of 128k which couldn't be read.
And it was rather hard to be able to clean this mess and get the bad block
back. In this case it was a video, so I just cut the bad part, but I was
frustrated about it.
That's about the time where I started to look elsewhere, for now I am using
btrfs, which lacks features compared to zfs, but which works well for me so
far (still using zfs for a volume where dedeup is useful though).
So I believe if you have the bad bit in a very bad place and the pool is
not mirrored, it must be very possible to indeed destroy the pool. But
since zfs is almost always about mirroring it's probably no danger for most
people !
Post by Gordan Bobic
That sounds like a lot of handwaving and hearsay. The point remains that
ZFS' design still makes it more resistant to issues like this than a
traditional file system. I'm happy to be persuaded otherwise, but I'd need
to see a specific case in which a single bit flip will destroy a ZFS pool
and conclusive proof that a single bit flip _cannot_ similarly destroy a
data set on a more traditional storage stack.
If the aim was to show that ZFS can be more risky than a traditional FS,
this falls well short. Especially since I can demonstrate that ZFS has
protected my data from damage due to silent disk corruption a large number
of times already.
Gordan
http://hardware.slashdot.org/**comments.pl?sid=4226771&cid=**44881099<http://hardware.slashdot.org/comments.pl?sid=4226771&cid=44881099>
This should point directly to the right comment !
Hi Folks,
Gordan: I agree with you (not that I condone the use of ECC-less
systems, but when it simply isn't an option as in most notebooks and
also embedded systems, I think things are much better off
reliability-wise with ZFS than with other file systems).
Emmanuel: can you mention any situation where ZFS would corrupt data
in an ECC-less system where another filesystem won't make at least
as much (and possibly much more) mess?
Cheers,
--
Durval.
On Fri, Sep 20, 2013 at 12:38 PM, Gordan Bobic
That doesn't entirely make sense. If you have a redundant pool,
then a detected error will cause recovery to be attempted. This
involves comparing the checksum of the block against
combinations of data blocks on the disks, and when the
combination that matches is found, the un-matching set is
overwritten to repair it.
This should ensure that unless you have a double error (e.g. in
both metadata AND data), a good working block still gets
recovered and overwritten. If a good block is erroneously
replaced with an identical good block due to a memory error, so
be it.
The point being that if the implementation is good and correct,
ZFS will still help even in face of ECC-less RAM erroring out.
On Fri, Sep 20, 2013 at 3:57 PM, Emmanuel Anne
About the checksum feature, I have read lately that if you
don't have ecc ram then it's adviced NOT to run any scrub,
because you increase the chances to destroy the pool when
nothing is actually wrong (but just because a bit of the ram
changed at the wrong time).
I had this false positive once, and it was only about a
single file, but it's very annoying, and I am not even sure
I had run any scrub at that time. So in a nutshell, without
ecc ram, these checksums can do more bad than good.
It was in the comments about the creation of the open-zfs
site on slashdot.
It would also be great if it worked (reliably!!) an a
typical home computer with around 2GB of ram. Not
everybody has 64GB of ram. Great if it worked on a 32
bit OS, too.
FWIW, I have ZFS-FUSE running on a pogoplug. 256MB RAM
ARM cpu. Not anything fancy, just a single disk zfs fs.
I wanted ZFS for the checksum feature.
On Fri, Sep 20, 2013 at 4:20 AM, Gordan Bobic
I cannot help but feel it would be quite awesome if
http://open-zfs.org/wiki/Main_**Page<http://open-zfs.org/wiki/Main_Page>
--
--
To post to this group, send email to
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed
to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving
emails from it, send an email to
**>.
For more options, visit
https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.
--
--
To post to this group, send email to
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to
the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to
**>.
For more options, visit
https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.
--
http://rainemu.swishparty.co.**uk/cgi-bin/gitweb.cgi?p=zfs;a=
**summary<http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary>
--
--
To post to this group, send email to
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the
Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to
**>.
For more options, visit
https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the
Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from
**>.
For more options, visit https://groups.google.com/**
groups/opt_out <https://groups.google.com/groups/opt_out>.
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it,
**>.
For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.
--
http://rainemu.swishparty.co.**uk/cgi-bin/gitweb.cgi?p=zfs;a=**summary<http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary>
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send
.
For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.
--
--
To visit our Web site, click on http://zfs-fuse.net/
--- You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.
--
my zfs-fuse git repository :
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Gordan Bobic
2013-09-20 21:28:34 UTC
Permalink
Post by Emmanuel Anne
So I believe if you have the bad bit in a very bad place and the pool is
not mirrored, it must be very possible to indeed destroy the pool.
You could argue that about any non-redundant storage setup. I am talking
about a system with appropriate redundancy in the array/pool.
Post by Emmanuel Anne
But
since zfs is almost always about mirroring it's probably no danger for
most people !
The example is a bad one anyway. I still don't see how you can claim
that you are not at equal risk of losing a file due to an in-RAM bit
flip on any other FS. The only difference is that ZFS will detect the
error and tell you to restore the file from a backup. Other FS-es will
just silently feed you back duff data. Personally I prefer the ZFS way -
if something has gone fubar I'd rather know about it and restore the
file than be blissfully unaware and be bitten by consequences with no
warning.

Gordan
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Emmanuel Anne
2013-09-22 21:21:49 UTC
Permalink
Well all I can say is that it never happened to me since I use hard disks,
and so it's quite a long time already (1st hard disk must have been on the
atari st, so it was before 1990 !). Of course maybe it happened but I never
noticed it anyway, but the fact is that I never noticed any problem of this
kind so far.
With zfs it happened within 3 years, which is quite a short time, and where
a single bit flip could have almost no consequences on some types of files,
here it makes a whole 128k block totally unreadable, which actually makes
the file corrupt.
Anyway just remember to use mirroring and/or ecc ram and everything should
be fine, just avoid a single pool without ecc ram, that's all !
Post by Emmanuel Anne
So I believe if you have the bad bit in a very bad place and the pool is
Post by Emmanuel Anne
not mirrored, it must be very possible to indeed destroy the pool.
You could argue that about any non-redundant storage setup. I am talking
about a system with appropriate redundancy in the array/pool.
But
Post by Emmanuel Anne
since zfs is almost always about mirroring it's probably no danger for
most people !
The example is a bad one anyway. I still don't see how you can claim that
you are not at equal risk of losing a file due to an in-RAM bit flip on any
other FS. The only difference is that ZFS will detect the error and tell
you to restore the file from a backup. Other FS-es will just silently feed
you back duff data. Personally I prefer the ZFS way - if something has gone
fubar I'd rather know about it and restore the file than be blissfully
unaware and be bitten by consequences with no warning.
Gordan
--
--
To visit our Web site, click on http://zfs-fuse.net/
--- You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.
--
my zfs-fuse git repository :
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Daniel Brooks
2013-09-22 23:22:15 UTC
Permalink
Yes, in order to get the resilience that ZFS offers you must have some form
of redundancy in your pool. Mirrors or raidz, extra copies, and backups;
take as many as you can. One bit-flip every few years is pretty average; it
depends on how much data you read from the drive. As disk capacities go up
and file sizes increase it get more and more likely.

I wonder though if you could use zdb to get at the contents of the stripe
that suffered the bit-flip. Maybe that would let you restore the file.

db48x
Post by Emmanuel Anne
Well all I can say is that it never happened to me since I use hard disks,
and so it's quite a long time already (1st hard disk must have been on the
atari st, so it was before 1990 !). Of course maybe it happened but I never
noticed it anyway, but the fact is that I never noticed any problem of this
kind so far.
With zfs it happened within 3 years, which is quite a short time, and
where a single bit flip could have almost no consequences on some types of
files, here it makes a whole 128k block totally unreadable, which actually
makes the file corrupt.
Anyway just remember to use mirroring and/or ecc ram and everything should
be fine, just avoid a single pool without ecc ram, that's all !
Post by Emmanuel Anne
So I believe if you have the bad bit in a very bad place and the pool is
Post by Emmanuel Anne
not mirrored, it must be very possible to indeed destroy the pool.
You could argue that about any non-redundant storage setup. I am talking
about a system with appropriate redundancy in the array/pool.
But
Post by Emmanuel Anne
since zfs is almost always about mirroring it's probably no danger for
most people !
The example is a bad one anyway. I still don't see how you can claim that
you are not at equal risk of losing a file due to an in-RAM bit flip on any
other FS. The only difference is that ZFS will detect the error and tell
you to restore the file from a backup. Other FS-es will just silently feed
you back duff data. Personally I prefer the ZFS way - if something has gone
fubar I'd rather know about it and restore the file than be blissfully
unaware and be bitten by consequences with no warning.
Gordan
--
--
To visit our Web site, click on http://zfs-fuse.net/
--- You received this message because you are subscribed to the Google
Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
.
--
http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary
--
--
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/groups/opt_out.
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Gordan Bobic
2013-09-23 10:18:31 UTC
Permalink
Post by Emmanuel Anne
Well all I can say is that it never happened to me since I use hard disks,
and so it's quite a long time already (1st hard disk must have been on the
atari st, so it was before 1990 !). Of course maybe it happened but I never
noticed it anyway, but the fact is that I never noticed any problem of this
kind so far.
There are two factors here:
1) You were lucky that the corruption that occurred wasn't in places where
it did any harm for your uses
2) The corruption almost certainly occurred at various points, you just had
no way of knowing since you weren't running a FS that automatically detects
it.
Post by Emmanuel Anne
With zfs it happened within 3 years, which is quite a short time, and
where a single bit flip could have almost no consequences on some types of
files, here it makes a whole 128k block totally unreadable, which actually
makes the file corrupt.
Anyway just remember to use mirroring and/or ecc ram and everything should
be fine, just avoid a single pool without ecc ram, that's all !
You are comparing here two distinctly unsimilar situations.

1) Data corruption occurred but the data was still "good enough" so you
didn't care
2) Data corruption occurred, and the FS detected it and prevented you from
consuming broken data, thus inconveniencing you

Personally, I cannot think of a realistic non-home-use throwaway-data
situation where I would consider silent data corruption to be acceptable.
And since any data important enough to keep is also, IMO, important enough
to keep regularly backed up, I think the option of knowing about it
preferable - restore from backup and all is good again.

Then again, if you are running a pool with redundancy, ZFS will
transparently fix it up for you anyway. If you are running a pool without
redundancy, I would argue you have no right to complain about data
corruption/loss.

In the past 5 years I have seen disk models that have a
within-warranty-period failure rates of over 100% (as in, they all fail
within warranty, plus some of the warranty replacements as well, within the
original warranty period). There is a reason all disk manufacturers stopped
offering 5-year warranties on their desktop grade disks in 2009. Some
manufacturers disks (*cough*WD*cough*) also outright lie about their
defects (e.g. pending sector count does down but reallocated sector count
doesn't go up on a pending sector overwrite or secure erase). Reliability
of modern disks is such that they are, IMO, not fit for the purpose of
using them unless they are in ZFS arrays with substantial redundancy.

As somebody recently put it on another mailing list, it is a good idea to
look at modern disks not in terms of buying costs but in terms of lease
costs. Take the price of the disk and the length of the warranty. Assume
the disk is essentially guaranteed to fail within that period. therefore,
the TCO of a disk (assuming your array is redundant and backed up so you
don't suffer data loss) is:

($cost) / ($warranty_period)

Any usable live you get out of the disk after that is a bonus.

Gordan
--
--
To post to this group, send email to zfs-fuse-/***@public.gmane.org
To visit our Web site, click on http://zfs-fuse.net/
---
You received this message because you are subscribed to the Google Groups "zfs-fuse" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Loading...