Talk:ZFS/Archive 1

From Wikipedia, the free encyclopedia

Contents

[edit] Storage capacity

I'm removing this: "Sun believes that this capacity will never be reached, meaning that this filesystem will never need to be modified to increase its storage capacity. Although today such an assertion seems reasonable, a number of similar statements made in the past have been proven famously wrong." The quotes given on the only referenced sun page references Moore's law and give plenty of market spin ("According to Bonwick, it has to be. "Populating 128-bit file systems would exceed the quantum limits of earth-based storage. You couldn't fill a 128-bit storage pool without boiling the oceans.") but it is never stated that "Sun believes that this capacity will never be reached." Unsigned comment by 24.248.74.254 on 18:57, 9 June 2005 (UTC)

[edit] Regressing to stub

Thus far, Sun has not:

  • Released the file system yet
  • Given any hard technical details
  • Committed to shipping ZFS in 2005
  • Committed to the ZFS feature set

So, since Wikipedia is not a crystal ball, I think it would be best to remove most of the hype in this article and turn it back into a stub. —Ghakko 16:34, 18 July 2005 (UTC)

FYI, Regarding the release date. When I was in a Solaris 10 training class, the trainer mentioned that the ZFS developers plan on it being completed in Oct or Nov. However it has not been decided yet if ZFS will be released on it's own, or if it will be released with the first major update of Solaris 10, next spring. Also, the current version doesn't support ZFS as a boot device and when it is made public it probably won's support it either. That support will come later with an obp update. amRadioHed 01:38, 7 October 2005 (UTC)

ZFS is released, stub notice removed.

[edit] Comparison with other filesystems

Once the ZFS specs become clear, suggest the page at Comparison_of_file_systems is updated with ZFS details. --Oscarthecat 07:58, 7 November 2005 (UTC)

[edit] It's escaped.

Source and binary for ZFS have been released. see [1].

[edit] Requested move

Since the moniker for ZFS is now actually inaccurate (see [2]) and the other articles that expanded to ZFS were all redlinks, save for this one, this article should occupy the 'main' ZFS name. --moof 18:06, 22 November 2005 (UTC)

Done.--Commander Keane 18:58, 22 November 2005 (UTC)

[edit] Destubbify

I propose that the stub tag is long since obsolete and it should be removed. I propose to do so Monday, 11/28/05 unless there are serious objections. Georgewilliamherbert 20:13, 24 November 2005 (UTC)

  • Also, the Request for Expansion... no notes here in the discussion page or the RFE central page on what they were looking for, and the article seems expanded to me. I propose also removing that tag on 11/28/05 barring serious objections. Georgewilliamherbert 20:24, 24 November 2005 (UTC)

[edit] Technobabble

Some terms in this article are in dire need of clarification. e.g. "automatic length and stride detection" - sounds more like something from a triple-jump event, also "deadline scheduling" --OscarTheCattalk 10:03, 23 February 2006 (UTC)

I agree. The terms "volume management", "storage pool", "transactional object model", "block pointer", "target block", "metadata block", and "synchronous write semantics" need to be better explained. -P
In true encyclopedian manner, these should be linked to seperate articles where they are properly explained, but certainly not here. --Puellanivis 00:54, 23 August 2006 (UTC)
Some of these terms are industry generic, some are ZFS specific. The ZFS-specific ones should probably be explained here. The generic ones may either deserve WP pages or Wiktionary pages... Georgewilliamherbert 05:24, 23 August 2006 (UTC)

[edit] Advertisement for Sun?

Is it just me or does this whole article read like an advertisement? Ken 18:24, 24 April 2006 (UTC)

There are a few mentions, but it seems OK. I've removed one superfluous mention by re-writing two sentences. Mindmatrix 18:30, 24 April 2006 (UTC)

[edit] Stranded Storage

Sun's marketing states "stranded storage". I'd like to happily pretend this means I can mirror data onto a drive, unplug and walk offsite with the drive, walk back with the drive a week later, plug it in, and have it automatically sync up. But any real information on this would be appreciated. Myren 01:42, 7 June 2006 (UTC)

[edit] Looks like Apple's interested in porting ZFS too

See http://www.osnews.com/story.php?news_id=14473


[edit] Linux

Is there any info available about the status of the effort to port this to Linux? Is this an internal Sun thing? or is there a project surrounding it? The artcile doesn't make this very clear.. --Quasar 15:07, 9 July 2006 (UTC)

I believe that it would have to be integrated in the Linux kernel for support. That is impossible, seen as how the licenses of the Linux kernel and ZFS (GPL and CDDL) are not compatible. It's very unfortunate! —msikma <user_talk:msikma> 08:13, 24 August 2006 (UTC)
You can read about the project at http://code.google.com/soc/opsol/appinfo.html?csaid=1EEF6B271FE5408B It has links to the project home page and a blog detailing his progress. --NapoliRoma 13:08, 24 August 2006 (UTC)

[edit] "advert" for Sun.

Not added to the page as yet is that ZFS lacks transparent encryption, a la NTFS, and that presently only n+1 redundancy is possible. n+2 redundancy (RAID level 6) is also in the development branch only - via the OpenSolaris distribution. These omissions in the production branch of Solaris, as of Solaris 06/06 current release - do diminish ZFS's attractiveness in a lot of the situations at whiich the new FS is targeted. Adding to the talk page because never contributed to the wikippaedia before, and some double checking needed anyway. I've been evaluating ZFS for some weeks now, so i'm fairly sure i'm correct :) My point being that backing up huge FSs (24TB on the latest 4U Sun 4600 box) is an absolute b*tch, and n+2 redundancy and transparent encryption are nearly standard. The workaround i had, of using PGP command line to encrypt on a x86 OpenSolaris build doesn't fly because PGP commandline is SPARC only as of writing, and loading OpenSolaris (for the n+2) on a SPARC box of large capacity negates all the nice support contracts.

By the by, i think the capacity specs "2^64 — Number of devices in any zpool" etc. are redundant technicalia in the main entry. The quotes given to evaluate what these specs mean are better descriptive.

One last point, there is no context given for the development of ZFS in the main entry. e.g. how to stripe huge volumes for throughput, historic limitations of other FSs (NTFS I'm looking at you, when you hang a quad core Xeon if a folder gets more than 20,000 objects!), how the choice of copy on write giving the snapshots is probably influenced more by backup difficulties and so on.

Someone could make a point or two about how general purpose CPUs make a fair alternative to proprietary embedded OSs such as those used by Adaptec and LSI Logic (on Intel XScale)and how this means less data abstraction when things go badly wrong i.e. with the embedded controllers, you've no chance to talk to your files save as volumes via the embedded BIOS, should you get a corrupted drive.

Last, but not least, given Sun's recent product launches, there ought to be a comparison to similar capability (capacity, throughput) RAID systems, such as from DataDirect and the whole interconnect problem with such a large array (Infiniband? FC? 10GbE? Switching Latency? and hence maybe even a touch upon the forthcoming NiagraII Sun chip which has 10GbE on - die) . . . in other words, how do you take advantage of all the "specifications goodness" :)

Will leave this for more seasoned contributors to do with as they see fit, but will revisit sometime soon.

Kind regards to all.

[edit] Unicode Support?

Does ZFS uses Unicode natively, or even support it? I think that might be an interesting tibit to add to the article. --Saoshyant 14:13, 11 September 2006 (UTC)