[zfs-discuss] JBOD?
Hi I'm a little bit new with server but I'm going to dive in and build myself a server with opensolaris and zfs. Plan on going with 6-7x 1.5tb drives with raidz2. I've one question that I'd love to get an answere for. I've been reading everywhere it feels like and I see a lot of opensolaris+zfs+jbod. 1) Why should I have jbod on the controller card (well in my case on the motherboard since I'll use some mobo with 8 sata connectors). Does not zfs take care of all that? Or can someone help me clear this up a bit for me? Thanks! -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs replication via zfs send/recv dead after 2009.06 update
I had the same issue and did the following; * disabled the auto-snapshot services (enabled by default I think) * removed all auto-snapshots on the filesystems I wanted to send that were between the two snapshots I was referring to (start and end snapshot of the incremental) Then I could do the send and receive as per normal. Not sure if that will help you also, but thought it was worth putting up here. Cheers, Sally. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS tale of woe and fail
It is a ZFS issue. My understanding is that ZFS has multiple copies of the uberblock, but only tries to use the most recent one on import, meaning that on rare occasions, it's possible to loose access to the pool even though the vast majority of your data is fine. I believe there is work going on to create automatic recovery tools that will warn you of uberblock corruption, and attempt to automatically use an older copy, but I have no idea of the bug number nor status I'm afraid. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Q: zfs log device
I've also suggested this in the past, but I think the end result was that it was pointless: If you have sync writes, the client does not get a reply until the data is on disk. So a SSD drive makes a huge difference. If you have async writes, the client gets a reply as soon as the server has the data, before it gets to disk. So the disk speed makes no difference to response time. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] JBOD?
I think you're misunderstanding a little. JBOD = just a bunch of disks, it's an acronym used as shorthand for cards that don't have raid. So those standard sata connectors on your motherboard *are* JBOD :-) JBOD isn't an extra technology ZFS needs, it's just a way of saying it doesn't need RAID and that standard controllers work just fine. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS - SWAP and lucreate..
Thank you very much! This is exactly what i searched for! -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Hanging receive
I was doing an incremental send between pools, the receive side is locked up and no zfs/zpool commands work on that pool. The stacks look different from those reported in the earlier ZFS snapshot send/recv hangs X4540 servers thread. Here is the process information from scat (other commands hanging on the pool are also in cv_wait): SolarisCAT(live/10X) proc -L 18500 addr PIDPPID RUID/UID size RSS swresv time command == == == == == == = 0xffc8d1990398 18500 14729 05369856 2813952 1064960 32 zfs receive -v -d backup user (LWP_SYS) thread: 0xfe84e0d5bc20 PID: 18500 cmd: zfs receive -v -d backup t_wchan: 0xa0ed62a2 sobj: condition var (from zfs:txg_wait_synced+0x83) t_procp: 0xffc8d1990398 p_as: 0xfee19d29c810 size: 5369856 RSS: 2813952 hat: 0xfedb762d2818 cpuset: zone: global t_stk: 0xfe8000143f10 sp: 0xfe8000143b10 t_stkbase: 0xfe800013f000 t_pri: 59(TS) pctcpu: 0.00 t_lwp: 0xfe84e92d6ec0 lwp_regs: 0xfe8000143f10 mstate: LMS_SLEEP ms_prev: LMS_SYSTEM ms_state_start: 15 minutes 4.476756638 seconds earlier ms_start: 15 minutes 8.447715668 seconds earlier psrset: 0 last CPU: 2 idle: 102425 ticks (17 minutes 4.25 seconds) start: Thu Jul 2 22:23:06 2009 age: 1029 seconds (17 minutes 9 seconds) syscall: #54 ioctl(, 0x0) (sysent: genunix:ioctl+0x0) tstate: TS_SLEEP - awaiting an event tflg: T_DFLTSTK - stack is default size tpflg: TP_TWAIT - wait to be freed by lwp_wait TP_MSACCT - collect micro-state accounting information tsched: TS_LOAD - thread is in memory TS_DONT_SWAP - thread/LWP should not be swapped pflag: SKILLED - SIGKILL has been posted to the process SMSACCT - process is keeping micro-state accounting SMSFORK - child inherits micro-state accounting pc: unix:_resume_from_idle+0xf8 resume_return: addq $0x8,%rsp unix:_resume_from_idle+0xf8 resume_return() unix:swtch+0x12a() genunix:cv_wait+0x68() zfs:txg_wait_synced+0x83() zfs:dsl_sync_task_group_wait+0xed() zfs:dsl_sync_task_do+0x54() zfs:dmu_objset_create+0xc5() zfs:zfs_ioc_create+0xee() zfs:zfsdev_ioctl+0x14c() genunix:cdev_ioctl+0x1d() specfs:spec_ioctl+0x50() genunix:fop_ioctl+0x25() genunix:ioctl+0xac() unix:_syscall32_save+0xbf() -- switch to user thread's user stack -- The box is an x4500, Solaris 10u7. -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [cifs-discuss] [nfs-discuss] Why can't we write to files created in multi-protocol se
I can't really explain the changes that happen to the file's ACL using vi over NFS. I'm CC'ing zfs-discuss maybe someone there can help out. Afshin John Keiffer wrote: Looks like this: n...@leo-ha2:/$ ls -Vd ha2/f1/ drwxr-xr-x+ 3 enguser root 4 Jul 1 14:51 ha2/f1/ user:smb:rwxp-D-ARW-Co-:---:allow user:nfs:rwxp-D-ARW-Co-:---:allow owner@:--:---:deny owner@:rwxp---A-W-Co-:---:allow group@:-w-p--:---:deny group@:r-x---:---:allow everyone@:-w-p---A-W-Co-:---:deny everyone@:r-x---a-R-c--s:---:allow Thanks, John -Original Message- From: afshin.ardak...@sun.com [mailto:afshin.ardak...@sun.com] Sent: Wednesday, July 01, 2009 6:17 PM To: John Keiffer Cc: cifs-disc...@opensolaris.org Subject: Re: [cifs-discuss] [nfs-discuss] Why can't we write to files created in multi-protocol se How does the ACL for 'f1' look like? Afshin John Keiffer wrote: Well... I may have had an idamp problem before, which I believe I've now corrected. This is my current idamp config: add wingroup:Domain us...@matrix.lab unixgroup:group2 add winuser:engu...@matrix.lab unixuser:enguser wingroup:Domain adm...@matrix.lab == gid:2147483650 wingroup:Authenticated Users== gid:2147483651 wingroup:Network== gid:2147483652 wingroup:administrat...@builtin == gid:2147483653 I still have some questions regarding access from both CIFS and NFS: After steping on the file from Linux and vi with the ! I believe it reordered the ACL's like this: n...@leo-ha2:/$ ls -V ha2/f1/ total 2 --+ 1 enguser group2 6 Jul 1 14:32 cifs.txt group:group2:rwxp--:---:deny everyone@:r-xCo-:---:deny group:group2:-s:---:allow user:enguser:rwxpdDaARWcCos:fd-:allow everyone@:--a-R-c--s:---:allow Which means that when I try and access it from Windows I can't, because group2 has write deny (among other things). If I remove the user ACL and insert it at the beginning, I can write again from Windows... n...@leo-ha2:/$ chmod A3- ha2/f1/cifs.txt n...@leo-ha2:/$ chmod A0+user:enguser:rwxpdDaARWcCos:fd-:allow ha2/f1/cifs.txt n...@leo-ha2:/$ ls -V ha2/f1/ total 2 --+ 1 enguser group2 6 Jul 1 14:32 cifs.txt user:enguser:rwxpdDaARWcCos:fd-:allow group:group2:rwxp--:---:deny everyone@:r-xCo-:---:deny group:group2:-s:---:allow everyone@:--a-R-c--s:---:allow Until I ! save it again from Linux, because then the ACLs are changed (such that nobody can do much of anything because of the deny lines): n...@leo-ha2:/$ ls -V ha2/f1/cifs.txt -- 1 enguser group227 Jul 1 14:48 ha2/f1/cifs.txt owner@:rwxp--:---:deny owner@:---A-W-Co-:---:allow group@:rwxp--:---:deny group@:--:---:allow everyone@:rwxp---A-W-Co-:---:deny everyone@:--a-R-c--s:---:allow ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [cifs-discuss] [nfs-discuss] Why can't we write to files created in multi-protocol se
I only took a cursory look at the discussion below but I suspect that vi isn't just overwriting the file. If vi is saving a copy then doing an rm+rename thing, the ACL on the saved file was either inherited from the parent directory when the copy was saved or vi .attempted to copy the permissions from the original file but, because of NFS, the destination doesn't quite get the same ACL. Try changing the parent directory ACL such that the inheritable ACEs look correct for newly created files, i.e. when you make a new file over NFS, does the ACL turn out the way you want. Then retry the scenario that's causing a problem. Alan -- On 07/01/09 18:55, Afshin Salek wrote: I can't really explain the changes that happen to the file's ACL using vi over NFS. I'm CC'ing zfs-discuss maybe someone there can help out. Afshin John Keiffer wrote: Looks like this: n...@leo-ha2:/$ ls -Vd ha2/f1/ drwxr-xr-x+ 3 enguser root 4 Jul 1 14:51 ha2/f1/ user:smb:rwxp-D-ARW-Co-:---:allow user:nfs:rwxp-D-ARW-Co-:---:allow owner@:--:---:deny owner@:rwxp---A-W-Co-:---:allow group@:-w-p--:---:deny group@:r-x---:---:allow everyone@:-w-p---A-W-Co-:---:deny everyone@:r-x---a-R-c--s:---:allow Thanks, John -Original Message- From: afshin.ardak...@sun.com [mailto:afshin.ardak...@sun.com] Sent: Wednesday, July 01, 2009 6:17 PM To: John Keiffer Cc: cifs-disc...@opensolaris.org Subject: Re: [cifs-discuss] [nfs-discuss] Why can't we write to files created in multi-protocol se How does the ACL for 'f1' look like? Afshin John Keiffer wrote: Well... I may have had an idamp problem before, which I believe I've now corrected. This is my current idamp config: add wingroup:Domain us...@matrix.lab unixgroup:group2 add winuser:engu...@matrix.lab unixuser:enguser wingroup:Domain adm...@matrix.lab == gid:2147483650 wingroup:Authenticated Users== gid:2147483651 wingroup:Network== gid:2147483652 wingroup:administrat...@builtin == gid:2147483653 I still have some questions regarding access from both CIFS and NFS: After steping on the file from Linux and vi with the ! I believe it reordered the ACL's like this: n...@leo-ha2:/$ ls -V ha2/f1/ total 2 --+ 1 enguser group2 6 Jul 1 14:32 cifs.txt group:group2:rwxp--:---:deny everyone@:r-xCo-:---:deny group:group2:-s:---:allow user:enguser:rwxpdDaARWcCos:fd-:allow everyone@:--a-R-c--s:---:allow Which means that when I try and access it from Windows I can't, because group2 has write deny (among other things). If I remove the user ACL and insert it at the beginning, I can write again from Windows... n...@leo-ha2:/$ chmod A3- ha2/f1/cifs.txt n...@leo-ha2:/$ chmod A0+user:enguser:rwxpdDaARWcCos:fd-:allow ha2/f1/cifs.txt n...@leo-ha2:/$ ls -V ha2/f1/ total 2 --+ 1 enguser group2 6 Jul 1 14:32 cifs.txt user:enguser:rwxpdDaARWcCos:fd-:allow group:group2:rwxp--:---:deny everyone@:r-xCo-:---:deny group:group2:-s:---:allow everyone@:--a-R-c--s:---:allow Until I ! save it again from Linux, because then the ACLs are changed (such that nobody can do much of anything because of the deny lines): n...@leo-ha2:/$ ls -V ha2/f1/cifs.txt -- 1 enguser group227 Jul 1 14:48 ha2/f1/cifs.txt owner@:rwxp--:---:deny owner@:---A-W-Co-:---:allow group@:rwxp--:---:deny group@:--:---:allow everyone@:rwxp---A-W-Co-:---:deny everyone@:--a-R-c--s:---:allow ___ cifs-discuss mailing list cifs-disc...@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Interposing on readdir and friends
We've just stumbled across an interesting problem in one of our applications that fails when run on a ZFS filesystem. I don't have the code, so I can't fix it at source, but it's relying on the fact that if you do readdir() on a directory, the files come back in the order they were added to the directory. This appears to be true (within certain limitations) on UFS, but certainly isn't true on ZFS. Is there any way to force readdir() to return files in a specific order? (On UFS, we have a scipt that creates symlinks in the correct order. Ugly, but seems to have worked for many years.) If not, I was looking at interposing my own readdir() (that's assuming the application is using readdir()) that actually returns the entries in the desired order. However, I'm having a bit of trouble hacking this together (the current source doesn't compile in isolation on my S10 machine). -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Interposing on readdir and friends
We've just stumbled across an interesting problem in one of our applications that fails when run on a ZFS filesystem. I don't have the code, so I can't fix it at source, but it's relying on the fact that if you do readdir() on a directory, the files come back in the order they were added to the directory. This appears to be true (within certain limitations) on UFS, but certainly isn't true on ZFS. Is there any way to force readdir() to return files in a specific order? (On UFS, we have a scipt that creates symlinks in the correct order. Ugly, but seems to have worked for many years.) No. In UFs a readdir is a file and all new files are added at the end unless there's room before the end. ZFS uses Btrees and returns them in btree order. If not, I was looking at interposing my own readdir() (that's assuming the application is using readdir()) that actually returns the entries in the desired order. However, I'm having a bit of trouble hacking this together (the current source doesn't compile in isolation on my S10 machine). I think this is going to be rather difficult; I think you want to interposing opendir() also and read all the files first before you start returning them. Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Interposing on readdir and friends
On Thu, Jul 2, 2009 at 8:07 AM, Peter Tribblepeter.trib...@gmail.com wrote: We've just stumbled across an interesting problem in one of our applications that fails when run on a ZFS filesystem. I don't have the code, so I can't fix it at source, but it's relying on the fact that if you do readdir() on a directory, the files come back in the order they were added to the directory. This appears to be true (within certain limitations) on UFS, but certainly isn't true on ZFS. Is there any way to force readdir() to return files in a specific order? (On UFS, we have a scipt that creates symlinks in the correct order. Ugly, but seems to have worked for many years.) If not, I was looking at interposing my own readdir() (that's assuming the application is using readdir()) that actually returns the entries in the desired order. However, I'm having a bit of trouble hacking this together (the current source doesn't compile in isolation on my S10 machine). Is one of these your starting point? What errors are you seeing? http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/gen/readdir.c http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libbc/libc/gen/common/readdir.c The libbc version hasn't changed since the code became public. You can get to an older libc variant of it by clicking on the history link or using the appropriate hg command to get a specific changeset. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Interposing on readdir and friends
Peter Tribble peter.trib...@gmail.com wrote: We've just stumbled across an interesting problem in one of our applications that fails when run on a ZFS filesystem. I don't have the code, so I can't fix it at source, but it's relying on the fact that if you do readdir() on a directory, the files come back in the order they were added to the directory. This appears to be true (within certain limitations) on UFS, but certainly isn't true on ZFS. It seems that you found a software that is not POSIX compliant as it expects a behavior that is not granted by POSIX. Is there any way to force readdir() to return files in a specific order? (On UFS, we have a scipt that creates symlinks in the correct order. Ugly, but seems to have worked for many years.) You could write a readdir() replacement that calls struct dirent * (*readdir_real)() = dlsym(RTLD_NEXT, readdir); and enforce it via LDPRELOAD= ...but how would you retrieve the creation order? Also note that you would need to read in the whole directory into allocated storage first. BTW: If you like to fix the software, you should know that Linux has at least one filesystem that returns the entries for . and .. out of order. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS, ESX ,and NFS. oh my!
On Jul 1, 2009, at 10:58 PM, Brent Jones br...@servuhome.net wrote: On Wed, Jul 1, 2009 at 7:29 PM, HUGE | David Stahldst...@hugeinc.com wrote: The real benefit of the of using a separate zvol for each vm is the instantaneous cloning of a machine, and the clone will take almost no additional space initially. In our case we build a template VM and then provision our development machines from this. However the limit of 32 nfs mounts per esx machine is kind of a bummer. -Original Message- From: zfs-discuss-boun...@opensolaris.org on behalf of Steve Madden Sent: Wed 7/1/2009 8:46 PM To: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] ZFS, ESX ,and NFS. oh my! Why the use of zvols, why not just; zfs create my_pool/group1 zfs create my_pool/group1/vm1 zfs create my_pool/group1/vm2 and export my_pool/group1 If you don't want the people in group1 to see vm2 anymore just zfs rename it to a different group. I'll admit I am coming into this green - but if you're not doing iscsi, why zvols? SM. -- Is there a supported way to multipath NFS? Thats one benefit to iSCSI is your VMware can multipath to a target to get more speed/HA... Yes, it's called IPMP on Solaris. Define two interfaces in a common group with no failover (used to probe network failures) then define any number of virtual interfaces on each and if one interface goes down the virtual interfaces will fail-over to the other physical interface. It will also do load balancing between them, or you can create a LAG which does redundancy and load balancing. -Ross ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] JBOD?
On Thu, 02 Jul 2009 01:45:28 PDT, Ross no-re...@opensolaris.org wrote: I think you're misunderstanding a little. JBOD = just a bunch of disks, it's an acronym used as shorthand for cards that don't have raid. So those standard sata connectors on your motherboard *are* JBOD :-) You're right. There is a reason for this misunderstanding: a few years ago one could buy 1 TB external (USB) disks, which contained two physical 500 GB disks, probably concatenated or striped by the controller, which where presented to the outside world as one 1 TB disk. They used to call that a JBOD. Nowadays it's more common to use the word JBOD to indicate a set of individually addressable disks indeed. JBOD isn't an extra technology ZFS needs, it's just a way of saying it doesn't need RAID and that standard controllers work just fine. -- ( Kees Nuyt ) c[_] ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Q: zfs log device
True, but the ZIL is designed to only hold a small amount of data anyway, so I'm not sure the cost of the ZIL device would be less than the equivalent RAM for the sizes we're talking about. There may be a few cases that would benefit, but I don't think there are enough that Sun would put the effort into making the change. -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Interposing on readdir and friends
On Thu, Jul 2, 2009 at 9:21 AM, Joerg Schillingjoerg.schill...@fokus.fraunhofer.de wrote: Peter Tribble peter.trib...@gmail.com wrote: We've just stumbled across an interesting problem in one of our applications that fails when run on a ZFS filesystem. I don't have the code, so I can't fix it at source, but it's relying on the fact that if you do readdir() on a directory, the files come back in the order they were added to the directory. This appears to be true (within certain limitations) on UFS, but certainly isn't true on ZFS. It seems that you found a software that is not POSIX compliant as it expects a behavior that is not granted by POSIX. Is there any way to force readdir() to return files in a specific order? (On UFS, we have a scipt that creates symlinks in the correct order. Ugly, but seems to have worked for many years.) You could write a readdir() replacement that calls struct dirent * (*readdir_real)() = dlsym(RTLD_NEXT, readdir); I don't think this part is necessary - it seems as though readdir needs to be replaced, not wrapped. As such, readdir_real would never be called. and enforce it via LDPRELOAD= ...but how would you retrieve the creation order? Sort on crtime? $ ls -l -% all .bashrc -rw-r--r-- 1 mgerdts other 4674 Jul 2 06:18 .bashrc timestamp: atime Jul 2 09:51:44 2009 timestamp: ctime Jul 2 06:18:06 2009 timestamp: mtime Jul 2 06:18:06 2009 timestamp: crtime May 14 09:24:35 2009 getattrat(3C) seems to be the man page to look at for this value. My guess is that this is going to be extremely slow on the first call to readdir with the need to read the entire directory contents, call getattrat on every entry, then sort. However, slow is often better than broke. Also note that you would need to read in the whole directory into allocated storage first. It seems as though readdir will already do this for smallish (8KB) directories. BTW: If you like to fix the software, you should know that Linux has at least one filesystem that returns the entries for . and .. out of order. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] [cifs-discuss] [nfs-discuss] Why can't we write to files created in multi-protocol se
Mark, Does it matter that the share IS mounted nfsv4? From the client: bash-3.1$ mount ip:/volumes/ha2/f1 on /mnt/leo1/nfsv3 type nfs4 (rw,addr=ip) bash-3.1$ pwd /mnt/leo1/nfsv3 bash-3.1$ nfs4_getfacl . A::s...@matrix:rwaDxTnNCo A::nobody:rwaDxTnNCo D::OWNER@: A::OWNER@:rwaxTNCo D:g:GROUP@:wa A:g:GROUP@:rx D::EVERYONE@:waTC A::EVERYONE@:rxtncy bash-3.1$ nfs4_getfacl cifs.txt D::OWNER@:rwax A::OWNER@:TNCo D:g:GROUP@:rwax A:g:GROUP@: D::EVERYONE@:rwaxTC A::EVERYONE@:tncy This system can't do 'ls -V', so I'm having to use nfs4_getfacl instead (not as convienient). Thanks, John -Original Message- From: mark.shellenb...@sun.com [mailto:mark.shellenb...@sun.com] Sent: Thursday, July 02, 2009 6:16 AM To: Afshin Salek Cc: John Keiffer; zfs-discuss@opensolaris.org; cifs-disc...@opensolaris.org Subject: Re: [zfs-discuss] [cifs-discuss] [nfs-discuss] Why can't we write to files created in multi-protocol se Afshin Salek wrote: I can't really explain the changes that happen to the file's ACL using vi over NFS. I'm CC'ing zfs-discuss maybe someone there can help out. Afshin This is caused by vim trying to preserve ACLs and the NFSv3 server making some bad assumptions. What is happening is that vim tries to find out what if any POSIX draft ACLs exist on the file. POSIX draft ACLs aren't supported by ZFS and the file system returns ENOSYS. The NFS server sees this error and is afraid that returning that error will cause problems for the client so it fabricates an ACL based on the mode bits of the file. This causes vim to see an ACL that equates to a mode of 000. Then after writing the data vim restores an ACL that equates to the mode. The NFS server actually translates the POSIX draft ACL into a NFSv4 ACL and that is the ACL you actual see on the file after the exiting vim. Here is the snipit of code from NFS that actually causes the problem http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_acl_srv.c#98 The assumption made in the comment really aren't accurate anymore. Solaris can generally deal with an error from VOP_GETSECATTR() now and probably predates ZFS being integrated into ON. There are a couple of ways to work around the problem. - Recompile vim without ACL support. - Use NFSv4 instead of NFSv3 This really should be a bug that needs to be investigated by the NFS team to determine if/when they really need to fabricate an ACL. I would guess they probably don't need to do that anymore. -Mark John Keiffer wrote: Looks like this: n...@leo-ha2:/$ ls -Vd ha2/f1/ drwxr-xr-x+ 3 enguser root 4 Jul 1 14:51 ha2/f1/ user:smb:rwxp-D-ARW-Co-:---:allow user:nfs:rwxp-D-ARW-Co-:---:allow owner@:--:---:deny owner@:rwxp---A-W-Co-:---:allow group@:-w-p--:---:deny group@:r-x---:---:allow everyone@:-w-p---A-W-Co-:---:deny everyone@:r-x---a-R-c--s:---:allow Thanks, John -Original Message- From: afshin.ardak...@sun.com [mailto:afshin.ardak...@sun.com] Sent: Wednesday, July 01, 2009 6:17 PM To: John Keiffer Cc: cifs-disc...@opensolaris.org Subject: Re: [cifs-discuss] [nfs-discuss] Why can't we write to files created in multi-protocol se How does the ACL for 'f1' look like? Afshin John Keiffer wrote: Well... I may have had an idamp problem before, which I believe I've now corrected. This is my current idamp config: add wingroup:Domain us...@matrix.lab unixgroup:group2 add winuser:engu...@matrix.lab unixuser:enguser wingroup:Domain adm...@matrix.lab == gid:2147483650 wingroup:Authenticated Users== gid:2147483651 wingroup:Network== gid:2147483652 wingroup:administrat...@builtin == gid:2147483653 I still have some questions regarding access from both CIFS and NFS: After steping on the file from Linux and vi with the ! I believe it reordered the ACL's like this: n...@leo-ha2:/$ ls -V ha2/f1/ total 2 --+ 1 enguser group2 6 Jul 1 14:32 cifs.txt group:group2:rwxp--:---:deny everyone@:r-xCo-:---:deny group:group2:-s:---:allow user:enguser:rwxpdDaARWcCos:fd-:allow everyone@:--a-R-c--s:---:allow Which means that when I try and access it from Windows I can't, because group2 has write deny (among other things). If I remove the user ACL and insert it at the beginning, I can write again from Windows... n...@leo-ha2:/$ chmod A3- ha2/f1/cifs.txt n...@leo-ha2:/$ chmod A0+user:enguser:rwxpdDaARWcCos:fd-:allow ha2/f1/cifs.txt n...@leo-ha2:/$ ls -V ha2/f1/ total 2 --+ 1 enguser group2 6 Jul 1 14:32 cifs.txt user:enguser:rwxpdDaARWcCos:fd-:allow
Re: [zfs-discuss] [cifs-discuss] [nfs-discuss] Why can't we write to files created in multi-protocol se
John Keiffer wrote: Mark, Does it matter that the share IS mounted nfsv4? I'm not sure. In a cursory look at the nfsv4 server code it looks like it would also fabricate an ACL. I don't know what translations if any the linux client does before sending it over to Solaris. I will CC nfs-disc...@opensolaris.org and couple of engineers who will most likely know. -Mark From the client: bash-3.1$ mount ip:/volumes/ha2/f1 on /mnt/leo1/nfsv3 type nfs4 (rw,addr=ip) bash-3.1$ pwd /mnt/leo1/nfsv3 bash-3.1$ nfs4_getfacl . A::s...@matrix:rwaDxTnNCo A::nobody:rwaDxTnNCo D::OWNER@: A::OWNER@:rwaxTNCo D:g:GROUP@:wa A:g:GROUP@:rx D::EVERYONE@:waTC A::EVERYONE@:rxtncy bash-3.1$ nfs4_getfacl cifs.txt D::OWNER@:rwax A::OWNER@:TNCo D:g:GROUP@:rwax A:g:GROUP@: D::EVERYONE@:rwaxTC A::EVERYONE@:tncy This system can't do 'ls -V', so I'm having to use nfs4_getfacl instead (not as convienient). Thanks, John -Original Message- From: mark.shellenb...@sun.com [mailto:mark.shellenb...@sun.com] Sent: Thursday, July 02, 2009 6:16 AM To: Afshin Salek Cc: John Keiffer; zfs-discuss@opensolaris.org; cifs-disc...@opensolaris.org Subject: Re: [zfs-discuss] [cifs-discuss] [nfs-discuss] Why can't we write to files created in multi-protocol se Afshin Salek wrote: I can't really explain the changes that happen to the file's ACL using vi over NFS. I'm CC'ing zfs-discuss maybe someone there can help out. Afshin This is caused by vim trying to preserve ACLs and the NFSv3 server making some bad assumptions. What is happening is that vim tries to find out what if any POSIX draft ACLs exist on the file. POSIX draft ACLs aren't supported by ZFS and the file system returns ENOSYS. The NFS server sees this error and is afraid that returning that error will cause problems for the client so it fabricates an ACL based on the mode bits of the file. This causes vim to see an ACL that equates to a mode of 000. Then after writing the data vim restores an ACL that equates to the mode. The NFS server actually translates the POSIX draft ACL into a NFSv4 ACL and that is the ACL you actual see on the file after the exiting vim. Here is the snipit of code from NFS that actually causes the problem http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/nfs/nfs_acl_srv.c#98 The assumption made in the comment really aren't accurate anymore. Solaris can generally deal with an error from VOP_GETSECATTR() now and probably predates ZFS being integrated into ON. There are a couple of ways to work around the problem. - Recompile vim without ACL support. - Use NFSv4 instead of NFSv3 This really should be a bug that needs to be investigated by the NFS team to determine if/when they really need to fabricate an ACL. I would guess they probably don't need to do that anymore. -Mark John Keiffer wrote: Looks like this: n...@leo-ha2:/$ ls -Vd ha2/f1/ drwxr-xr-x+ 3 enguser root 4 Jul 1 14:51 ha2/f1/ user:smb:rwxp-D-ARW-Co-:---:allow user:nfs:rwxp-D-ARW-Co-:---:allow owner@:--:---:deny owner@:rwxp---A-W-Co-:---:allow group@:-w-p--:---:deny group@:r-x---:---:allow everyone@:-w-p---A-W-Co-:---:deny everyone@:r-x---a-R-c--s:---:allow Thanks, John -Original Message- From: afshin.ardak...@sun.com [mailto:afshin.ardak...@sun.com] Sent: Wednesday, July 01, 2009 6:17 PM To: John Keiffer Cc: cifs-disc...@opensolaris.org Subject: Re: [cifs-discuss] [nfs-discuss] Why can't we write to files created in multi-protocol se How does the ACL for 'f1' look like? Afshin John Keiffer wrote: Well... I may have had an idamp problem before, which I believe I've now corrected. This is my current idamp config: add wingroup:Domain us...@matrix.lab unixgroup:group2 add winuser:engu...@matrix.lab unixuser:enguser wingroup:Domain adm...@matrix.lab == gid:2147483650 wingroup:Authenticated Users== gid:2147483651 wingroup:Network== gid:2147483652 wingroup:administrat...@builtin == gid:2147483653 I still have some questions regarding access from both CIFS and NFS: After steping on the file from Linux and vi with the ! I believe it reordered the ACL's like this: n...@leo-ha2:/$ ls -V ha2/f1/ total 2 --+ 1 enguser group2 6 Jul 1 14:32 cifs.txt group:group2:rwxp--:---:deny everyone@:r-xCo-:---:deny group:group2:-s:---:allow user:enguser:rwxpdDaARWcCos:fd-:allow everyone@:--a-R-c--s:---:allow Which means that when I try and access it from Windows I can't, because group2 has write deny (among other things). If I remove the user ACL and insert it at the beginning, I can write again from Windows... n...@leo-ha2:/$
Re: [zfs-discuss] JBOD?
some controllers still create jbods in the same way. A perfect example is any of the highpoint controllers. But yah, when we say JBOD we mean it as it was originally intended..just a bunch of discs On Thu, Jul 2, 2009 at 10:23 AM, Kees Nuyt k.n...@zonnet.nl wrote: On Thu, 02 Jul 2009 01:45:28 PDT, Ross no-re...@opensolaris.org wrote: I think you're misunderstanding a little. JBOD = just a bunch of disks, it's an acronym used as shorthand for cards that don't have raid. So those standard sata connectors on your motherboard *are* JBOD :-) You're right. There is a reason for this misunderstanding: a few years ago one could buy 1 TB external (USB) disks, which contained two physical 500 GB disks, probably concatenated or striped by the controller, which where presented to the outside world as one 1 TB disk. They used to call that a JBOD. Nowadays it's more common to use the word JBOD to indicate a set of individually addressable disks indeed. JBOD isn't an extra technology ZFS needs, it's just a way of saying it doesn't need RAID and that standard controllers work just fine. -- ( Kees Nuyt ) c[_] ___ 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] Ditto blocks on RAID-Z pool.
Hello all, If you have copies=2 on a large enough raid-z(2) pool and 2(3) disks die, is it possible to recover that information despite the offline state of the pool? I don't have this happening to me, it's just a theoretical question. So, if you can't recover the data, is there any advantage to using ditto blocks on top of raid-z(2)? Jebnor -- Louis-Frédéric Feuillette jeb...@gmail.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] JBOD?
I appreciate the info and for clearing this up for me. Thanks -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Ditto blocks on RAID-Z pool.
Louis-Frédéric Feuillette wrote: Hello all, If you have copies=2 on a large enough raid-z(2) pool and 2(3) disks die, is it possible to recover that information despite the offline state of the pool? I don't have this happening to me, it's just a theoretical question. So, if you can't recover the data, is there any advantage to using ditto blocks on top of raid-z(2)? Yes, there is an advantage. But it is not for the case where the whole disk completely fails. The advantage of copies is when the data cannot be read, which is occurs more often than whole disk failure. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS write I/O stalls
On Thu, 2 Jul 2009, Zhu, Lejun wrote: Actually it seems to be 3/4: 3/4 is an awful lot. That would be 15 GB on my system, which explains why the 5 seconds to write rule is dominant. It seems that both rules are worthy of re-consideration. There is also still the little problem that zfs is incable of reading during all/much of the time it is syncing a TXG. Even if the TXG is written more often, readers will still block, resulting in a similar cumulative effect on performance. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Interposing on readdir and friends
On Thu, 2 Jul 2009, Peter Tribble wrote: We've just stumbled across an interesting problem in one of our applications that fails when run on a ZFS filesystem. I don't have the code, so I can't fix it at source, but it's relying on the fact that if you do readdir() on a directory, the files come back in the order they were added to the directory. This appears to be true (within certain limitations) on UFS, but certainly isn't true on ZFS. Is there any way to force readdir() to return files in a specific order? (On UFS, we have a scipt that creates symlinks in the correct order. Ugly, but seems to have worked for many years.) Oops! The only solution is to add some code to sort the results. You can use qsort() for that. Depending on existing directory order is an error. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS, ESX ,and NFS. oh my!
rw == Ross Walker rswwal...@gmail.com writes: rw you can create a LAG which does redundancy and load balancing. be careful---these aggregators are all hash-based, so the question is, of what is the hash taken? The widest scale on which the hash can be taken is L4 (TCP source/dest port numbers) because this type of aggregation only preserves packet order within a single link, and reordering packets is ``bad'', not sure why exactly, but I presume it hurts TCP performance, so the way around that problem is to keep each TCP flow nailed to a particular physical link. It looks like there's a 'dladm -P L4' option so I imagine L4 hashing is supported on the transmit side *iff* you explicitly ask for it. though sometimes things like that might be less or more performant depending on the NIC you buy, I can't imagine a convincing story why it would be in this case. so that handles the TRANSMIT direction. The RECEIVE direction is another story. Application-layer multipath uses a different source IP address for the two sessions, so both sent and received traffic will be automatically spread over the two NIC's. With LACP-style aggregation it's entirely the discretion of each end of the link how they'd like to divide up transmitted traffic. Typically switches hash L2 MAC only, which is obviously useless. It's meant for switching trunks with many end systems on either side. host-switch is covered by dladm above, but if you want L4 hashing for packets in the switch-host direction you must buy an L3 switch and configure it ``appropriately'', which seems to be described here for cisco 6500: http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.1E/native/configuration/guide/channel.html#wp1020804 I believve it's layer-violating feature, so it works fine on a port channel in an L2 VLAN. You don't have to configure a /30 router-style non-VLAN two-host-subnet interface on the 6500 to use L4 hashing, I think. however the Cisco command applies to all port channels on the entire switch!!, including trunks to other switches, so the network team is likely to give lots of push-back when you ask them to turn this knob. IMHO it's not harmful, and they should do it for you, but maybe they will complain about SYN-flood vulnerability and TCAM wastage and wait but how does it interact with dCEF and FUDFUDFUD and all the things they usually say whenever you want to actually use any feature of the 6500 instead of just bragging about its theoretical availability. Finally, *ALL THIS IS COMPLETELY USELESS FOR NFS* because L4 hashing can only split up separate TCP flows. I checked with a Linux client and Solaris host, and it puts all the NFSv3 mounts onto a single TCP flow, not one mount per flow. iSCSI seems to do one flow per session, while I bet multiple LUN's (comstar-style) would share the same TCP flow for several LUN's. so...as elegant as network-layer multipath is, I think you'll need SCSI-layer multipath to squeeze more performance from an aggregated link between two physical hosts. And if you are using network-layer multipath (such as a port-aggregated trunk) carrying iSCSI it might work better to (a) make sure the equal-cost-multipath hash you're using is L4, not L3 or L2, and (b) use a single LUN per session (multiple flows per target). This might also be better on very recent versions of Solaris (something later than snv_105) which also have 10Gbit network cards even without any network ECMP because the TCP stack can supposedly divide TCP flows among the CPU's: http://www.opensolaris.org/os/project/crossbow/topics/nic/ I'm not sure, though. The data path is getting really advanced, and there are so many optimisations conflicting with each other at this point. Maybe it's better to worry about this optimisation for http clients, and forget about it entirely for iSCSI u.s.w. and instead try to scheme for a NIC that can do SRP or iSER/iWARP. There's a downside to it, too. Multiple TCP flows will use more switch buffers when going from a faster link into a slower or shared link than a single flow, so if you have a 3560 or some other switch with small output queues, reading a wide RAID stripe could in theory overwhelm the switch when all the targets answer at once. If this happens, you should be able to see dropped packet counters incrementing in the switch. FC and IB are both lossless and does not have this problem. If you're not using any port-aggregated trunks and don't have 10Gbit/s, the TCP flow control might work better to avoid this ``microbursting'' if you use multi LUN per flow, multiplexing all the LUN's onto a single TCP flow per initiator/target pair Comstar-style (or, well, NFS-style). (all pretty speculative, though. YMMV.) pgp7Risyci3Tw.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Copy data from zfs datasets
I 've few data sets in my zfs pool which has been exported to the non global zones and i want to copy data on those datasets/file systems to my datasets in new pool mounted on global zone, how can i do that ? -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Interposing on readdir and friends
I am no expert, but I recently wrote a wrapper for my Media players, that expands .RAR archives, and presents files inside as regular contents of the directory. It may give you a starting point; wikihttp://lundman.net/wiki/index.php/Librarchy tarball http://www.lundman.net/ftp/librarcy/librarcy-1.0.3.tar.gz CVSweb http://www.lundman.net/cvs/viewvc.cgi/lundman/librarcy/ Lund Peter Tribble wrote: We've just stumbled across an interesting problem in one of our applications that fails when run on a ZFS filesystem. I don't have the code, so I can't fix it at source, but it's relying on the fact that if you do readdir() on a directory, the files come back in the order they were added to the directory. This appears to be true (within certain limitations) on UFS, but certainly isn't true on ZFS. Is there any way to force readdir() to return files in a specific order? (On UFS, we have a scipt that creates symlinks in the correct order. Ugly, but seems to have worked for many years.) If not, I was looking at interposing my own readdir() (that's assuming the application is using readdir()) that actually returns the entries in the desired order. However, I'm having a bit of trouble hacking this together (the current source doesn't compile in isolation on my S10 machine). -- Jorgen Lundman | lund...@lundman.net Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo| +81 (0)90-5578-8500 (cell) Japan| +81 (0)3 -3375-1767 (home) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Copy data from zfs datasets
On Fri 03/07/09 01:13 , Ketan no-re...@opensolaris.org sent: I 've few data sets in my zfs pool which has been exported to the non global zones and i want to copy data on those datasets/file systems to my datasets in new pool mounted on global zone, how can i do that ? You should be able to snapshot and zfs send them from the global zone. An alternative is to halt the zone, clear the zoned property of the filesystem and copy the data. -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] ZFS, ESX ,and NFS. oh my!
According to the link bellow, VMWare will only use a single TCP session for NFS data, which means you're unlikely to get it to travel down more than one interface on the VMware side, even if you can find a way to do it on the solaris side. http://virtualgeek.typepad.com/virtual_geek/2009/06/a-multivendor-post-t o-help-our-mutual-nfs-customers-using-vmware.html T -Original Message- From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Brent Jones Sent: Thursday, 2 July 2009 12:58 PM To: HUGE | David Stahl Cc: Steve Madden; zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] ZFS, ESX ,and NFS. oh my! On Wed, Jul 1, 2009 at 7:29 PM, HUGE | David Stahldst...@hugeinc.com wrote: The real benefit of the of using a separate zvol for each vm is the instantaneous cloning of a machine, and the clone will take almost no additional space initially. In our case we build a template VM and then provision our development machines from this. However the limit of 32 nfs mounts per esx machine is kind of a bummer. -Original Message- From: zfs-discuss-boun...@opensolaris.org on behalf of Steve Madden Sent: Wed 7/1/2009 8:46 PM To: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] ZFS, ESX ,and NFS. oh my! Why the use of zvols, why not just; zfs create my_pool/group1 zfs create my_pool/group1/vm1 zfs create my_pool/group1/vm2 and export my_pool/group1 If you don't want the people in group1 to see vm2 anymore just zfs rename it to a different group. I'll admit I am coming into this green - but if you're not doing iscsi, why zvols? SM. -- This message posted from opensolaris.org ___ 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 Is there a supported way to multipath NFS? Thats one benefit to iSCSI is your VMware can multipath to a target to get more speed/HA... -- Brent Jones br...@servuhome.net ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] how l2arc works?
Hello, I was wondering if someone could point me to any information describing how the l2arc works? I attached an SSD as a cache device to the root pool of a 2009.11 system. Although the cache has started filling up (zpool iostat -v) it just seems that when I do a reboot, I hear quite a bit of disk activity. I was hoping, in the best case, that most of the disk access that was needed to boot would have been served though the SSD. Does the cache fill only on writes? And what is the cache replacement policy if/when the cache becomes full? I did notice some information regarding how limiting the speed at which the l2arc populates, and I think bug 6748030 discusses a turbo warmup. Thanks for any information. --joe ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Open Solaris version recommendation? b114, b117?
We have been told we can have support for OpenSolaris finally, so we can move the ufs on zvol over to zfs with user-quotas. Does anyone have any feel for the versions of Solaris that has zfs user quotas? We will put it on the x4540 for customers. I have run b114 for about 5 weeks, and have yet to experience any problems. But b117 is what 2010/02 version will be based on, so perhaps that is a better choice. Other versions worth considering? I know it's a bit vague, but perhaps there is a known panic in a certain version that I may not be aware. Lund -- Jorgen Lundman | lund...@lundman.net Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo| +81 (0)90-5578-8500 (cell) Japan| +81 (0)3 -3375-1767 (home) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] how l2arc works?
For now L2ARC will have to be warmed up every time a reboot happens. See 6662467. From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Joseph Mocker Sent: 2009年7月3日 7:51 To: zfs-discuss@opensolaris.org Subject: [zfs-discuss] how l2arc works? Hello, I was wondering if someone could point me to any information describing how the l2arc works? I attached an SSD as a cache device to the root pool of a 2009.11 system. Although the cache has started filling up (zpool iostat -v) it just seems that when I do a reboot, I hear quite a bit of disk activity. I was hoping, in the best case, that most of the disk access that was needed to boot would have been served though the SSD. Does the cache fill only on writes? And what is the cache replacement policy if/when the cache becomes full? I did notice some information regarding how limiting the speed at which the l2arc populates, and I think bug 6748030 discusses a turbo warmup. Thanks for any information. --joe ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
