zfs discuss - Jun 2007 - Mac OS X 10.5 read-only support for ZFS

Toby Thain wrote:
> What possible use is "read only" ZFS?
A user of an OS that _does_ support read+write ZFS might, for  
example, have one spare USB disk/drive.

The user may opt for ZFS for that one disk, gaining the benefits of  
COW, rollback etc..

The user will be able to read (only) that disk when he connects it to  
a computer running Mac OS X 10.5.

The whole read-only business sounds like baloney to me. Read-only ZFS
implies that the file system would be created elsewhere - and I don''t
know
if there will be continuing compatibility between
Solaris/Linux(FUSE)/FreeBSD implementations - so they would presumably
support read-only of Solaris'' reference implementation. How many people
use
Solaris on desktop and want to let their Mac read-only their removable ZFS
drive? Obviously Apple would not bother with such a feature.
I see only 2 logical explanations for nonsense coming from Apple on the
topic, and that is:

- It is not going to be ready for Leopard release, so they are pretending
that they really meant to make it read-only all along, because they
can''t
stand saying that they failed to get a feature ready.
- Jobs is peeved at Sun''s boss and his minions now are struggling to
reconcile the fact that ZFS is showing up in beta, while wanting to pretend
that Sun and ZFS don''t exist.

On a related topic, does anyone know if there is built-in iSCSI support in
latest Leopard beta? I saw some Disk Utility screenshots in the past that
had a "Mount iSCSI" menu.

On 6/13/07, Graham Perrin <grahamperrin at gmail.com>
wrote:
>
> Toby Thain wrote:
>
> > What possible use is "read only" ZFS?
>
> A user of an OS that _does_ support read+write ZFS might, for
> example, have one spare USB disk/drive.
>
> The user may opt for ZFS for that one disk, gaining the benefits of
> COW, rollback etc..
>
> The user will be able to read (only) that disk when he connects it to
> a computer running Mac OS X 10.5.
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070613/435464ac/attachment.html>

Here''s one possible reason that a read-only ZFS would be useful:
DVD-ROM distribution.

Sector errors on DVD are not uncommon. Writing a DVD in ZFS format with
duplicated data blocks would help protect against that problem, at the cost of
50% or so disk space. That sounds like a lot, but with BluRay etc. coming along,
maybe paying a 50% penalty isn''t too bad. (And if ZFS eventually
supports RAID on a single disk, the penalty would be less.)

Note that Mac OS X includes read-only NTFS support already, so it''s not
totally surprising that a read-only ZFS implementation would be delivered.
 
 
This message posted from opensolaris.org

Anton B. Rang wrote:
> Here''s one possible reason that a read-only ZFS would be useful:
DVD-ROM distribution.
built-in compression works for DVDs, too.
> Sector errors on DVD are not uncommon. Writing a DVD in ZFS format with
duplicated data blocks would help protect against that problem, at the cost of
50% or so disk space. That sounds like a lot, but with BluRay etc. coming along,
maybe paying a 50% penalty isn''t too bad. (And if ZFS eventually
supports RAID on a single disk, the penalty would be less.)
Also, traditionally, CD and DVD-ROMs have poor path data protection.
ZFS''s end-to-end error checking is an advantage in such environments.
  -- richard-who-barely-survived-a-flaky-CD-ROM-cable-incident

> > Here''s one possible reason that a read-only ZFS would be
useful: DVD-ROM distribution.
> 
> built-in compression works for DVDs, too.
> 
> > Sector errors on DVD are not uncommon. Writing a DVD in ZFS format
with duplicated data blocks would help protect against that problem, at the cost
of 50% or so disk space. That sounds like a lot, but with BluRay etc. coming
along, maybe paying a 50% penalty isn''t too bad. (And if ZFS eventually
supports RAID on a single disk, the penalty would be less.)
> 
> Also, traditionally, CD and DVD-ROMs have poor path data protection.
> ZFS''s end-to-end error checking is an advantage in such
environments.
>   -- richard-who-barely-survived-a-flaky-CD-ROM-cable-incident
See my ZFSCD posts from earlier.

ZFS currently doesn''t support mounting from read-only volumes.
I''d plead
a case to consider temporary zpools, where ZFS doesn''t even consider
writing the in-use flags, which actually posed the problem in my tests,
and mounts the filesystem as real read-only. But then again, who''s
going
to burn ZFSCDs or ZFSDVDs in the short term (I would, but hit a
roadblock)?

I mean, there are a few nice benefits, which are the reason I tried this
in the first place. Checksums, improved data integrity, escalator
sorting aswell as ZFS prefetching. Especially the latter might be
convenient for performance on CD/DVD drives, e.g. with applications that
sequentially read data from discs, but instead of prefetching issue tons
of small requests (virtually all audio and video players known to man).

Also, where does this single disk RAID notion come from? This sounds
actually interesting. Is this a project actually in progress or to be
considered? Sure, it doesn''t prevent data loss on disk failure, however
may improve the safety of your data a lot without plain out losing half
your disk space due to simple mirroring.

-mg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: This is a digitally signed message part
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070618/8876dc43/attachment.bin>

On 18 June, 2007 - Mario Goebbels sent me these 3,2K bytes:
> Also, where does this single disk RAID notion come from? This sounds
> actually interesting. Is this a project actually in progress or to be
> considered? Sure, it doesn''t prevent data loss on disk failure,
however
> may improve the safety of your data a lot without plain out losing half
> your disk space due to simple mirroring.
http://blogs.sun.com/bill/entry/ditto_blocks_the_amazing_tape

http://blogs.sun.com/relling/entry/zfs_copies_and_data_protection

/Tomas
-- 
Tomas ?gren, stric at acc.umu.se, http://www.acc.umu.se/~stric/
|- Student at Computing Science, University of Ume?
`- Sysadmin at {cs,acc}.umu.se

> > Also, where does this single disk RAID notion come from? This sounds
> > actually interesting. Is this a project actually in progress or to be
> > considered? Sure, it doesn''t prevent data loss on disk
failure, however
> > may improve the safety of your data a lot without plain out losing
half
> > your disk space due to simple mirroring.
> 
> http://blogs.sun.com/bill/entry/ditto_blocks_the_amazing_tape
> 
> http://blogs.sun.com/relling/entry/zfs_copies_and_data_protection
Those are ditto blocks, basically mirroring. Under single disk RAID, I
understand parity striping on the same physical disk, with a user
defined ratio (i.e. one parity stripe for every 3 data stripes).

-mg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 648 bytes
Desc: This is a digitally signed message part
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070618/2500b6b6/attachment.bin>

On Sun, Jun 17, 2007 at 09:38:51PM -0700, Anton B. Rang
wrote:
> Sector errors on DVD are not uncommon. Writing a DVD in ZFS format
> with duplicated data blocks would help protect against that problem, at
> the cost of 50% or so disk space. That sounds like a lot, but with
> BluRay etc. coming along, maybe paying a 50% penalty isn''t too
bad.
> (And if ZFS eventually supports RAID on a single disk, the penalty
> would be less.)
It would be an interesting project to create some software that took a
directory (or ZFS filesystem) to be written to a CD or DVD and optimized
the layout for redundancy. That is, choose the compression method (if
any), and then, in effect, partition the CD for RAID-Z or mirroring to
stretch the data to fill the entire disc. It wouldn''t necessarily be
all
that efficient to access, but it would give you resiliency against media
errors.

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl