[zfs-discuss] ZFS receive -dFv creates an extra e subdirectory..
Hi; After some very hairy testing, I came up with the following procedure for sending a zfs send datastream to a gzip staging file and later "receiving" it back to the same filesystem in the same pool. The above was to enable the filesystem data to be dedup. However, after the final ZFS received, i noticed that the same ZFS filesystem mountpoint had changed by itself and added an extra "e" subdirectory. Here is the procedure Firstly, the zfs file system in question has the following children.. o...@sunlight:/root# zfs list -t all -r myplace/Docs NAME USED AVAIL REFER MOUNTPOINT myplace/Docs 3.37G 1.05T 3.33G /export/home/admin/Docs -- NOTE ORIGINAL MOUNTPOINT (see later bug below) myplace/d...@scriptsnap2 43.0M - 3.33G - myplace/d...@scriptsnap3 0 - 3.33G - -- latest snapshot myplace/d...@scriptsnap1 0 - 3.33G - As root, i did r...@sunlight:/root# zfs send -R myplace/d...@scriptsnap3 | gzip -9c /var/tmp/myplace-Docs.snapshot.gz Then I attempted to test a zfs receive by using the "-n" option... ad...@sunlight:/var/tmp$ gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dnv myplace cannot receive new filesystem stream: destination 'myplace/Docs' exists must specify -F to overwrite it Ok...let's specify -F... ad...@sunlight:/var/tmp$ gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dFnv myplace cannot receive new filesystem stream: destination has snapshots (eg. myplace/d...@scriptsnap1) must destroy them to overwrite it Ok fine...let's destroy the existing snapshots for myplace/Docs... ad...@sunlight:/var/tmp$ zfs list -t snapshot -r myplace/Docs NAME USED AVAIL REFER MOUNTPOINT myplace/d...@scriptsnap2 43.0M - 3.33G - myplace/d...@scriptsnap3 0 - 3.33G - myplace/d...@scriptsnap1 0 - 3.33G - r...@sunlight:/root# zfs destroy myplace/d...@scriptsnap2 r...@sunlight:/root# zfs destroy myplace/d...@scriptsnap1 r...@sunlight:/root# zfs destroy myplace/d...@scriptsnap3 Checking... r...@sunlight:/root# zfs list -t all -r myplace/Docs NAME USED AVAIL REFER MOUNTPOINT myplace/Docs 3.33G 1.05T 3.33G /export/home/admin/Docs Ok...no more snapshots, just the parent myplace/Docs and no children... Let's try the zfs receive command yet again with a "-n" r...@sunlight:/root# gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dFnv myplace would receive full stream of myplace/d...@scriptsnap2 into myplace/d...@scriptsnap2 would receive incremental stream of myplace/d...@scriptsnap3 into myplace/d...@scriptsnap3 Looks great! OK...let's go for the real thing... r...@sunlight:/root# gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dFv myplace receiving full stream of myplace/d...@scriptsnap2 into myplace/d...@scriptsnap2 received 3.35GB stream in 207 seconds (16.6MB/sec) receiving incremental stream of myplace/d...@scriptsnap3 into myplace/d...@scriptsnap3 received 47.6MB stream in 6 seconds (7.93MB/sec) Yah...looks good! BUT... A zfs list of myplace/Docs I get.. r...@sunlight:/root# zfs list -r myplace/Docs NAME USED AVAIL REFER MOUNTPOINT myplace/Docs 3.37G 1.05T 3.33G /export/home/admin/Docs/e/Docs --- *** Here is the extra "e/Docs".. r...@sunlight:/root# zfs set mountpoint=/export/home/admin/Docs myplace/Docs cannot mount '/export/home/admin/Docs': directory is not empty property may be set but unable to remount filesystem Ok... I then went to remove the e/Docs directory under /export/home/admin/Docs and it is now only /export/home/admin/Docs... Then.. r...@sunlight:/root# zfs set mountpoint=/export/home/admin/Docs myplace/Docs And all is well again.. Where did the "e/Docs" come from? Did I do something wrong? Warmest Regards Steven Sim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] dedup existing data
Hello; How do we dedup existing data? Will a ZFS send to an output file in a temporary staging area in the same pool and a subsequent reconstruct (zfs receive) from the file be sufficient? Or do I have to completely move the data out of the pool and back in again? Warmest Regards Steven Sim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] dedup existing data
Darren; A zfs send | zfs receive onto the same filesystem??? er... I tried the following... #zfs snapshot myplace/myd...@prededup The above created the following... ad...@sunlight:~$ zfs list -t snapshot -r myplace/mydata NAME USED AVAIL REFER MOUNTPOINT myplace/myd...@scriptsnap1 675K - 289M - myplace/myd...@scriptsnap2 675K - 289M - myplace/myd...@scriptsnap3 476K - 289M - myplace/myd...@prededup0 - 289M - Snapshot created manually ad...@sunlight:~$ The snapshots named scriptsnap was created by a rotating zfs snapshot script i wrote, one which i CRON to run every night... er... then.. r...@sunlight:/root# zfs send myplace/myd...@prededup | zfs receive -v myplace/mydata cannot receive new filesystem stream: destination 'myplace/fujitsu' exists must specify -F to overwrite it r...@sunlight:/root# zfs send myplace/myd...@prededup | zfs receive -Fv myplace/mydata cannot receive new filesystem stream: destination has snapshots (eg. myplace/myd...@scriptsnap3) must destroy them to overwrite it Could you advice I am guessing I must destroy all related snapshots first? Warmest Regards Steven Sim Darren J Moffat wrote: Steven Sim wrote: Hello; How do we dedup existing data? Currently by running a zfs send | zfs recv. Will a ZFS send to an output file in a temporary staging area in the same pool and a subsequent reconstruct (zfs receive) from the file be sufficient? Yes but you can avoid the temp file and just do zfs send | zfs recv. Or do I have to completely move the data out of the pool and back in again? That is what zfs send and recv actually does. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Single Instancing across the entire pool or only per filesystem
Hello; Is the ZFS dedup single instancing across the entire pool or is it only single instance inside each filesystem and not across the entire pool? Warmest Regards Steven Sim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs receive bug? Extra e directory?
Hi; After some very hairy testing, I came up with the following procedure for sending a zfs send datastream to a gzip staging file and later receiving it back to the same filesystem in the same pool. The above was to enable the filesystem data to be dedup. Here is the procedure and under careful examination there seems to be a bug (my mistake?) at the end Firstly, the zfs file system in question has the following children.. o...@sunlight:/root# zfs list -t all -r myplace/Docs NAME USED AVAIL REFER MOUNTPOINT myplace/Docs 3.37G 1.05T 3.33G /export/home/admin/Docs -- NOTE ORIGINAL MOUNTPOINT (see later bug below) myplace/d...@scriptsnap2 43.0M - 3.33G - myplace/d...@scriptsnap3 0 - 3.33G - -- latest snapshot myplace/d...@scriptsnap1 0 - 3.33G - As root, i did r...@sunlight:/root# zfs send -R myplace/d...@scriptsnap3 | gzip -9c /var/tmp/myplace-Docs.snapshot.gz Then I attempted to test a zfs receive by using the -n option... ad...@sunlight:/var/tmp$ gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dnv myplace cannot receive new filesystem stream: destination 'myplace/Docs' exists must specify -F to overwrite it Ok...let's specify -F... ad...@sunlight:/var/tmp$ gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dFnv myplace cannot receive new filesystem stream: destination has snapshots (eg. myplace/d...@scriptsnap1) must destroy them to overwrite it Ok fine...let's destroy the existing snapshots for myplace/Docs... ad...@sunlight:/var/tmp$ zfs list -t snapshot -r myplace/Docs NAME USED AVAIL REFER MOUNTPOINT myplace/d...@scriptsnap2 43.0M - 3.33G - myplace/d...@scriptsnap3 0 - 3.33G - myplace/d...@scriptsnap1 0 - 3.33G - r...@sunlight:/root# zfs destroy myplace/d...@scriptsnap2 r...@sunlight:/root# zfs destroy myplace/d...@scriptsnap1 r...@sunlight:/root# zfs destroy myplace/d...@scriptsnap3 Checking... r...@sunlight:/root# zfs list -t all -r myplace/Docs NAME USED AVAIL REFER MOUNTPOINT myplace/Docs 3.33G 1.05T 3.33G /export/home/admin/Docs Ok...no more snapshots, just the parent myplace/Docs and no children... Let's try the zfs receive command yet again with a -n r...@sunlight:/root# gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dFnv myplace would receive full stream of myplace/d...@scriptsnap2 into myplace/d...@scriptsnap2 would receive incremental stream of myplace/d...@scriptsnap3 into myplace/d...@scriptsnap3 Looks great! OK...let's go for the real thing... r...@sunlight:/root# gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dFv myplace receiving full stream of myplace/d...@scriptsnap2 into myplace/d...@scriptsnap2 received 3.35GB stream in 207 seconds (16.6MB/sec) receiving incremental stream of myplace/d...@scriptsnap3 into myplace/d...@scriptsnap3 received 47.6MB stream in 6 seconds (7.93MB/sec) Yah...looks good! BUT... A zfs list of myplace/Docs I get.. r...@sunlight:/root# zfs list -r myplace/Docs NAME USED AVAIL REFER MOUNTPOINT myplace/Docs 3.37G 1.05T 3.33G /export/home/admin/Docs/e/Docs --- WHAT? Where in the world did the extra e/Docs come from? UH? r...@sunlight:/root# zfs set mountpoint=/export/home/admin/Docs myplace/Docs cannot mount '/export/home/admin/Docs': directory is not empty property may be set but unable to remount filesystem Ok... I then went to remove the e/Docs directory under /export/home/admin/Docs and it is now only /export/home/admin/Docs... Then.. r...@sunlight:/root# zfs set mountpoint=/export/home/admin/Docs myplace/Docs And all is well again.. Where did the e come from? Did I do something wrong? Warmest Regards Steven Sim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS CIFS, smb.conf (smb/server) and LDAP
All; I am deeply sorry if this topic has been rehashed, checksummed, de-duplicated and archived before. But I just need a small clarification. /etc/sfw/smb.conf is necessary only for smb/server to function properly but is smb/server SMF service necessary for ZFS sharesmb to work I am trying to setup an open solaris file server acting as a Windows PDC with SAMBA/LDAP integration on the open solaris box. (with ZFS of course...) I read a BLOG which says ZFS CIFS has nothing to do with smb/server but it seems i cannot get ZFS sharesmb to work without smb/server SMF service. What exactly is the dependency here? On a separate note, I've actually gotten the shares to work and also successfully gotten the Windows Previous Version tab relating to ZFS snapshots. It's awesome! But now I'm facing a heck of a lot of problems getting SAMBA integrated with LDAP. (not this list i know..) For any interested and willing to advice I am using Sun DSEE 7.0 and I'm facing a heck of a lot of problems with the LDAP DIT structure. Warmest Regards Steven Sim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS Deduplication Replication
Hello; Dedup on ZFS is an absolutely wonderful feature! Is there a way to conduct dedup replication across boxes from one dedup ZFS data set to another? Warmest Regards Steven Sim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS snapshot successfully but zfs list -r does not list the snapshot
Gurus; I am using OpenSolaris 2008.11 snv_101b_rc2 X86 Prior to this I was using SXCE built 91 (or thereabout) On build 91, after the command #zfs snapshot -r myplace I could easily see the snapshot using ZFS list. But after install OpenSolaris 2008.11 snv 101b, I once again created a snapshot using zfs snapshot. r...@sunlight:/root# zfs snapshot -r mypl...@first r...@sunlight:/root# echo $? 0 But subsequent attempts to use zfs list simply does not list the snapshot, only the original volumes and file systems. r...@sunlight:/root# zfs list -r myplace NAMEUSED AVAIL REFER MOUNTPOINT myplace1.06T 1.61T 28.4K /myplace myplace/Docs 3.23G 1.61T 3.23G /export/home/admin/Docs myplace/fedora 26.9K 1.61T 26.9K /export/home/admin/vbox/fedora myplace/home 17.9G 1.61T 17.9G /export/home myplace/projects 5.41G 1.61T 5.41G /export/home/admin/projects myplace/solaris9.30G 1.61T 9.30G /export/home/admin/vbox/solaris myplace/solzone1.58G 18.4G 1.58G /myplace/solzone myplace/windoze26.9K 1.61T 26.9K /export/home/admin/vbox/windoze I can easily remove the snapshot using #zfs destroy -r mypl...@first and this proves the snapshot was successfully created (besides the fact that the zfs snapshot command returned a zero exit code). r...@sunlight:/root# r...@sunlight:/root# zfs destroy -r mypl...@first r...@sunlight:/root# echo $? 0 Has there been a change in the interface? Warmest Regards Steven Sim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] At Wits End for ZFS Permission Settings
All; I do apologize for making this query in this list. But I am at my wits end. I have a directory like so $ ls -l total 47 drwxr-xr-x 19 adminadmin 23 Feb 27 17:52 Named drw-r- 74 adminadmin556 Feb 25 03:46 Not Sorted --- Directory in Question $ ls -dv Not Sorted drw-r- 74 adminadmin556 Feb 25 03:46 Not Sorted 0:owner@:execute:deny 1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory /append_data/write_xattr/write_attributes/write_acl/write_owner :allow 2:group@:add_file/write_data/add_subdirectory/append_data/execute:deny 3:group@:list_directory/read_data:allow 4:everyone@:list_directory/read_data/add_file/write_data /add_subdirectory/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5:everyone@:read_xattr/read_attributes/read_acl/synchronize:allow But I cannot access the directory Not Sorted as user admin AT ALL. I changed my root path to ensure that chmod points to the chmod in /usr/bin as opposed to /usr/gnu/bin (sorry, but i really think that placing the GNU chmod first in the default root path is a real dum idea) I then did (as root) #chmod -R A- Not Sorted in an attempt to remove all ACL. Didn't work. I tried setting the entire ACL manually via (again as root) #chmod -R A=owner@:read_data/write_data:allow,group@:read_data:allow Not Sorted drw-r- 74 adminadmin556 Feb 25 03:46 Not Sorted --- Directory in Question Didn't work either. User admin is still unable to enter. Again as root #chmod -R A=owner@:read_data/write_data:allow,group@:read_data:allow Not Sorted #ls -dv Not Sorted drw-r-+ 74 adminadmin556 Feb 25 03:46 Not Sorted 0:user:admin:list_directory/read_data/add_file/write_data:allow 1:group@:list_directory/read_data:allow 2:owner@:execute:deny 3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory /append_data/write_xattr/write_attributes/write_acl/write_owner :allow 4:group@:add_file/write_data/add_subdirectory/append_data/execute:deny 5:group@:list_directory/read_data:allow 6:everyone@:list_directory/read_data/add_file/write_data /add_subdirectory/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 7:everyone@:read_xattr/read_attributes/read_acl/synchronize:allow User admin STILL cannot go in! What gives? Warmest Regards Steven Sim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS: unreliable for professional usage?
Tim; The proper procedure for ejecting a USB drive in Windows is to right click the device icon and eject the appropriate listed device. I've done this before without ejecting and lost data before. My personal experience with ZFS is that it is very reliable FS. I've not lost data on it yet even after several hardware upgrades, abrupt failures and recently an unofficial unsanction expansion technique. The folks at Sun who developed this earnestly believe in their product. Sometimes, these belief can translate to an uneven reply. For my own reasons, I too believe whole heartedly in ZFS. (I don't work in Sun nor do I own any share in Sun). Perhaps we can all work together and find the proper solution here. Logic dictates that ZFS can survive an abrupt failure far better than traditional VM/FS combination. The end to end checking summing simply do not exist in traditional methodologies. Could you describe in detail the kind of IO access you were generating prior to pulling out the USB? Warmest Regards Steven Sim Tim wrote: On Tue, Feb 10, 2009 at 11:44 PM, Fredrich Maney fredrichma...@gmail.com wrote: Ah... an illiterate AND idiotic bigot. Have you even read the manual or *ANY* of the replies to your posts? *YOU* caused the situation that resulted in your data being corrupted. Not Sun, not OpenSolaris, not ZFS and not anyone on this list. Yet you feel the need to blame ZFS and insult the people that have been trying to help you understand what happened and why you shouldn't do what you did. #1 English is clearly not his native tongue. Calling someone idiotic and illiterate when they're doing as well as he is in a second language is not only inaccurate, it's "idiotic". ZFS is not a filesystem like UFS or Reiserfs, nor is it an LVM like SVM or VxVM. It is both a filesystem and a logical volume manager. As such, like all LVM solutions, there are two steps that you must perform to safely remove a disk: unmount the filesystem and quiesce the volume. That means you *MUST*, in the case of ZFS, issue 'umount filesystem' *AND* 'zpool export' before you yank the USB stick out of the machine. Effectively what you did was create a one-sided mirrored volume with one filesystem on it, then put your very important (but not important enough to bother mirroring or backing up) data on it. Then you unmounted the filesystem and ripped the active volume out of the machine. You got away with it a couple of times because just how good of a job the ZFS developers did at idiot proofing it, but when it finally got to the point where you lost your data, you came here to bitch and point fingers at everyone but the responsible party (hint, it's you). When your ignorance (and fault) was pointed out to you, you then resorted to personal attacks and slurs. Nice. Very professional. Welcome to the bit-bucket. All that and yet the fact remains: I've never "ejected" a USB drive from OS X or Windows, I simply pull it and go, and I've never once lost data, or had it become unrecoverable or even corrupted. And yes, I do keep checksums of all the data sitting on them and periodically check it. So, for all of your ranting and raving, the fact remains even a *crappy* filesystem like fat32 manages to handle a hot unplug without any prior notice without going belly up. --Tim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] ZFS Automatic Growth after replacing original disk with a larger sized disk
File systems within the ZFS Pool!! Awesome! Simply awesome! No other file system or volume manager I know has this absolutely wonderful ability. Certainly Enterprise system will not use this method to increase their storage space but it certainly proved a boon for me! Warmest Regards Steven Sim ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Trying to understand zfs RAID-Z
Darren and Henk; Firstly, thank you very much for both of your replies. I am very grateful indeed for you all taking time off to answer my questions. I understand RAID-5 quite well and from both of your RAID-Z description, I see that the RAID-Z parity is also a separate block on a separate disk. Very well. This is just like RAID-5. My confusion is simple. Would this not then give rise also to the write-hole vulnerability of RAID-5? Jeff Bonwick states "that there's no way to update two or more disks atomically, so RAID stripes can become damaged during a crash or power outage." If I understand correctly, then the parity block for RAID-Z are also written in two different atomic operations. As per RAID-5. (the only difference being each can be of a different stripe size). How then does it fit into Jeff's statement that "Every block is its own RAID-Z stripe?" ( Perhaps I misunderstood but I now think this statement is rather for the fact that RAID-Z has a variable stripe size rather than meaning each block holding it's own RAID-Z parity within itself. ) If the write-hole power outage situation as described by Jeff Bonwick occur, how does RAID-Z "beat" the RAID-5 write-hole vulnerability? Through each block's independant checksum held one level above in the metadata block? Is this correct? Or am I completely off course? Henk Langeveld wonderful character based diagrams describes what is basically a standard RAID-5 layout on 4 disks. How is RAID-Z any different from RAID-5? (except for the ability to stripe different sizes which gives allows RAID-Z to never have to do a read-modify-write. This increases performance very significantly but I am unable to relate this to the write-hole vulnerability issue). Warmest Regards Steven Sim Darren Dunham wrote: iRAID-Z is a data/parity scheme like RAID-5, ubbut it uses dynamic stripe width. Every block is its own RAID-Z stripe, regardless of blocksize. This means that every RAID-Z write is a full-stripe write./b/u This, when combined with the copy-on-write transactional semantics of ZFS, completely eliminates the RAID write hole. RAID-Z is also faster than traditional RAID because it never has to do read-modify-write./i"br br I am unable to relate the above statement to the diagram shown in the PDF file 'bzfs_last.pdf/b' entitled "bZFS THE LAST WORD IN FILE SYSTEMS/b" (also by Jeff Bonwick), on page 11.br On the copy I'm looking at page 11 is "Copy-On-Write Transactions". Note that this page is showing only the "copy on write" stuff (which is used on all pools) and doesn't show anything about raidz. I was wondering whether Jeff or some one knowledgeable would elaborate further on the above and also answer the following questions;br br ul liThe green and blue "blocks" shown in the diagram on page 11, do the represent actual physical blocks on individual disks or a single RAID-Z stripe write across multiple disks???/li They represent filesystem "data" (the leaves) and filesystem "metadata" (the blocks above the leaves). They're written to a pool that may have some form of redundancy (mirroring, raidz), but that level is not presented in this slide. liThe parity for RAID-Z, where is it?? Mentioned on page 17, but no diagram on this link. Bill Moore presented this talk to BayLisa several months ago, and used a very similar presentation, but it had a diagram on the "RAID-Z" slide (the one on page 17) showing the data and parity blocks used by a raidz pool. Looking through google, I see many links to similar ZFS presentations, but none with the diagram on that page. Ah, found one... http://www.snia.org/events/past/sdc2006/zfs_File_Systems-bonwick-moore.pdf Page 13 in that stack. Surely not the checksum stored together in the upper level direct and indirect block pointer? And if not and it is written as a separate block on another disks, then ...I am afraid I do not understandbr The parity is written as a separate block on a separate disk. It's very similar to how RAID4/RAID5 would write parity on another disk. It's just that for R4/R5, any given data block on disk can be immediately calculated to be part of a particular stripe on the storage (which has a particular parity block). In the case of raidz, the stripe has a maximum length set by the raidz columns, but it may be smaller than that. liCould someone please elaborate more on the statement "Every block is it's own RAID-Z stripe"??? The block being referred to is a single block across multiple disks or a single disk?br Every filesystem block (not disk block). So a single filesystem block that spans multiple disks. Fujitsu Asia Pte. Ltd. _ This e-mail is confidential and may also be privileged. If y
[zfs-discuss] Trying to understand zfs RAID-Z
Gurus; I am exceedingly impressed by the ZFS although it is my humble opinion that Sun is not doing enough evangelizing for it. But that's beside the point. I am writing to seek help in understanding the RAID-Z concept. Jeff Bonwick's weblog states the following; " RAID-Z is a data/parity scheme like RAID-5, but it uses dynamic stripe width. Every block is its own RAID-Z stripe, regardless of blocksize. This means that every RAID-Z write is a full-stripe write. This, when combined with the copy-on-write transactional semantics of ZFS, completely eliminates the RAID write hole. RAID-Z is also faster than traditional RAID because it never has to do read-modify-write." I am unable to relate the above statement to the diagram shown in the PDF file 'zfs_last.pdf' entitled "ZFS THE LAST WORD IN FILE SYSTEMS" (also by Jeff Bonwick), on page 11. I was wondering whether Jeff or some one knowledgeable would elaborate further on the above and also answer the following questions; The green and blue "blocks" shown in the diagram on page 11, do the represent actual physical blocks on individual disks or a single RAID-Z stripe write across multiple disks??? The parity for RAID-Z, where is it?? Surely not the checksum stored together in the upper level direct and indirect block pointer? And if not and it is written as a separate block on another disks, then ...I am afraid I do not understand Could someone please elaborate more on the statement "Every block is it's own RAID-Z stripe"??? The block being referred to is a single block across multiple disks or a single disk? My sincere apologies if the above questions seem trivial. But I am really struggling to reconcile the statement and the diagram. Warmest Regards Steven Sim Fujitsu Asia Pte. Ltd. _ This e-mail is confidential and may also be privileged. If you are not the intended recipient, please notify us immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] x86 CPU Choice for ZFS
Casper; Does this mean it would be a good practice to say increase the amount of memory and/or swap space we usually recommend if the customer intends to use ZFS very heavily? Sorry if this is a dumb question! Warmest Regards Steven Sim [EMAIL PROTECTED] wrote: Hello, What kind of x86 CPU does ZFS prefer? In particular, what kind of CPU is optimal when using RAID-Z with a large number of disks (8)? Does L2 cache size play a big role, 256kb vs 512kb vs 1MB? Are there any performance improvements when using a dual core or quad processor machine? The most important factor when selecting a CPU for ZFS is that is /must/ be a 64 bit CPU. It's very virtual memory hungry. (It works on 32 bit systems, but there are many limitations) Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss Fujitsu Asia Pte. Ltd. _ This e-mail is confidential and may also be privileged. If you are not the intended recipient, please notify us immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
