OpenZFS

[Gordan Bobic]

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

[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.

On Fri, Sep 20, 2013 at 4:20 AM, Gordan Bobic <gordan...@gmail.com> wrote:

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-...@googlegroups.com
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[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.

2013/9/20 ray vantassle <rayvan...@gmail.com>

--
my zfs-fuse git repository : http://rainemu.swishparty.co.uk/cgi-bin/gitweb.cgi?p=zfs;a=summary

[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...

2013/9/20 Emmanuel Anne <emmanu...@gmail.com>

[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.

[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.

[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

[Durval Menezes]

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.

[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.

[Emmanuel Anne]

http://hardware.slashdot.org/comments.pl?sid=4226771&cid=44881099

This should point directly to the right comment !

2013/9/20 Durval Menezes <durval....@gmail.com>

[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

On 09/20/2013 07:41 PM, Emmanuel Anne wrote:
> http://hardware.slashdot.org/comments.pl?sid=4226771&cid=44881099
>
> This should point directly to the right comment !
>
>
>
> 2013/9/20 Durval Menezes <durval....@gmail.com

> <mailto:durval....@gmail.com>>

> <mailto:rayvan...@gmail.com>>

>
> 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

> <gordan...@gmail.com <mailto:gordan...@gmail.com>>

> wrote:
>
> 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-...@googlegroups.com

> <mailto:zfs-...@googlegroups.com>

> 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+u...@googlegroups.com

> <mailto:zfs-fuse%2Bunsu...@googlegroups.com>.

> For more options, visit
> https://groups.google.com/groups/opt_out.
>
>
> --
> --
> To post to this group, send email to

> zfs-...@googlegroups.com <mailto:zfs-...@googlegroups.com>

> 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+u...@googlegroups.com

> <mailto:zfs-fuse%2Bunsu...@googlegroups.com>.

> 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-...@googlegroups.com <mailto:zfs-...@googlegroups.com>

> 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+u...@googlegroups.com

> <mailto:zfs-fuse%2Bunsu...@googlegroups.com>.

> For more options, visit
> https://groups.google.com/groups/opt_out.
>
>
> --
> --
> To post to this group, send email to zfs-...@googlegroups.com

> <mailto:zfs-...@googlegroups.com>

> 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+u...@googlegroups.com

> <mailto:zfs-fuse%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> --
> To post to this group, send email to zfs-...@googlegroups.com

> <mailto:zfs-...@googlegroups.com>

> 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+u...@googlegroups.com

> <mailto:zfs-fuse%2Bunsu...@googlegroups.com>.

[Emmanuel Anne]

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 !

2013/9/20 Gordan Bobic <gordan...@gmail.com>

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

On 09/20/2013 07:41 PM, Emmanuel Anne wrote:

http://hardware.slashdot.org/comments.pl?sid=4226771&cid=44881099

This should point directly to the right comment !



2013/9/20 Durval Menezes <durval....@gmail.com

<mailto:durval.menezes@gmail.com>>

                    <mailto:zfs-fuse@googlegroups.com>

                    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@googlegroups.com

                    <mailto:zfs-fuse%2Bunsu...@googlegroups.com>.

                    For more options, visit
                    https://groups.google.com/groups/opt_out.


                --
                --
                To post to this group, send email to

                zfs-...@googlegroups.com <mailto:zfs-fuse@googlegroups.com>

                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@googlegroups.com

                <mailto:zfs-fuse%2Bunsu...@googlegroups.com>.

                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-...@googlegroups.com <mailto:zfs-fuse@googlegroups.com>

            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@googlegroups.com

            <mailto:zfs-fuse%2Bunsu...@googlegroups.com>.

            For more options, visit
            https://groups.google.com/groups/opt_out.


        --
        --
        To post to this group, send email to zfs-...@googlegroups.com

        <mailto:zfs-fuse@googlegroups.com>

        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@googlegroups.com

        <mailto:zfs-fuse%2Bunsu...@googlegroups.com>.

        For more options, visit https://groups.google.com/groups/opt_out.


    --
    --
    To post to this group, send email to zfs-...@googlegroups.com

    <mailto:zfs-fuse@googlegroups.com>

    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@googlegroups.com

    <mailto:zfs-fuse%2Bunsu...@googlegroups.com>.

    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-...@googlegroups.com
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@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
--
To post to this group, send email to zfs-...@googlegroups.com

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@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Gordan Bobic]

On 09/20/2013 09:42 PM, Emmanuel Anne wrote:

> 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.

> 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

[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 !

2013/9/20 Gordan Bobic <gordan...@gmail.com>

On 09/20/2013 09:42 PM, Emmanuel Anne wrote:

--
--
To post to this group, send email to zfs-...@googlegroups.com
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@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Daniel Brooks]

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

To unsubscribe from this group and stop receiving emails from it, send an email to zfs-fuse+u...@googlegroups.com.

[Gordan Bobic]

On Sun, Sep 22, 2013 at 10:21 PM, Emmanuel Anne <emmanu...@gmail.com> wrote:

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.

 

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