[zfs-discuss] NFS performance?
Hi, I've been searching around on the Internet to fine some help with this, but have been unsuccessfull so far. I have some performance issues with my file server. I have an OpenSolaris server with a Pentium D 3GHz CPU, 4GB of memory, and a RAIDZ1 over 4 x Seagate (ST31500341AS) 1,5TB SATA drives. If I compile or even just unpack a tar.gz archive with source code (or any archive with lots of small files), on my Linux client onto a NFS mounted disk to the OpenSolaris server, it's extremely slow compared to unpacking this archive on the locally on the server. A 22MB .tar.gz file containng 7360 files takes 9 minutes and 12seconds to unpack over NFS. Unpacking the same file locally on the server is just under 2 seconds. Between the server and client I have a gigabit network, which at the time of testing had no other significant load. My NFS mount options are: rw,hard,intr,nfsvers=3,tcp,sec=sys. Any suggestions to why this is? Regards, Sigbjorn ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Confused about consumer drives and zfs can someone help?
There is alot there to reply to...but I will try and help... Re. TLER. Do not worry about TLER when using ZFS. ZFS will handle it either way and will NOT time out and drop the drive...it may wait a long time, but it will not time out and drop the drive - nor will it have an issue if you do enable TLER-ON (which sets time out to 7 seonds). I run both with TLER-ON (disks from an old mdadm raid array) and without (TLER-OFF) 1.5TB WDEADS. I can not speak for the WD EARS, but the WDEADS are fine in my home nas. I also run 1.5TB Samsung Green/Silencer series and Seagate 11's. Others swear by Hitachi. I would recommend the Samsung or Hitachi and not the new WD EARS which have that 4k sectors or whatever it is. Re the CPU, do not go low power Atom etc, go a newish Core2 duo...the power differential at idle is bugger all and when you want to use the nas, ZFS will make good use of the CPU. Honestly, sit down and do the calculations on power savings of a low power cpu and you'll see it's better to just not have that 5th beer on a friday - you'll save more money that way and be MUCH happier with your nas performance. re. cards...I use and recommend these 8-Port SUPERMICRO AOC-USASLP-L8I UIO SAS. They are cheap on e-bay, just work and are fast. Use them. You do want alot of ram I use 8GB, but you can use 4. Ram is cheap, ZFS loves ram, just buy 8. IMHO (and that of the best practice guide) - you should mirror the rpool (o/s disk). Just buy 2 cheap laptop drives and when installing choose to mirror them. I hope that helps. -- 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] NFS performance?
That's because NFS adds synchronous writes to the mix (e.g. the client needs to know certain transactions made it to nonvolatile storage in case the server restarts etc). The simplest safe solution, although not cheap, is to add an SSD log device to the pool. On 23 Jul 2010, at 08:11, Sigbjorn Lie sigbj...@nixtra.com wrote: Hi, I've been searching around on the Internet to fine some help with this, but have been unsuccessfull so far. I have some performance issues with my file server. I have an OpenSolaris server with a Pentium D 3GHz CPU, 4GB of memory, and a RAIDZ1 over 4 x Seagate (ST31500341AS) 1,5TB SATA drives. If I compile or even just unpack a tar.gz archive with source code (or any archive with lots of small files), on my Linux client onto a NFS mounted disk to the OpenSolaris server, it's extremely slow compared to unpacking this archive on the locally on the server. A 22MB .tar.gz file containng 7360 files takes 9 minutes and 12seconds to unpack over NFS. Unpacking the same file locally on the server is just under 2 seconds. Between the server and client I have a gigabit network, which at the time of testing had no other significant load. My NFS mount options are: rw,hard,intr,nfsvers=3,tcp,sec=sys. Any suggestions to why this is? Regards, Sigbjorn ___ 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
Re: [zfs-discuss] Confused about consumer drives and zfs can someone help?
I've found the Seagate 7200.12 1tb drives and Hitachi 7k2000 2TB drives to be by far the best. I've read lots of horror stories about any WD drive with 4k sectorsit'sbest to stay away from them. I've also read plenty of people say that the green drives are terrible. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] L2ARC and ZIL on same SSD?
On Wed, Jul 21, 2010 at 12:42 PM, Orvar Korvar knatte_fnatte_tja...@yahoo.com wrote: Are there any drawbacks to partition a SSD in two parts and use L2ARC on one partition, and ZIL on the other? Any thoughts? -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss It's not going to be as good as having separate but i can tell you that i did this on my home system and it was WELL worth it. I used one of the sandforce 1500 based SSD's 50 gb i used 9 gb for ZIL, and the rest for L2ARC. adding the zil gave me about 400-500% nfs write performance. Seeing as you can't ever use more than half your ram for ZIL anyways, the only real downside to doing this is that i/o becomes split between zil and L2arc but realistically it depends on your workloadfor mine, i noticed a HUGE benefit from doing this. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
On Fri, Jul 23, 2010 at 3:11 AM, Sigbjorn Lie sigbj...@nixtra.com wrote: Hi, I've been searching around on the Internet to fine some help with this, but have been unsuccessfull so far. I have some performance issues with my file server. I have an OpenSolaris server with a Pentium D 3GHz CPU, 4GB of memory, and a RAIDZ1 over 4 x Seagate (ST31500341AS) 1,5TB SATA drives. If I compile or even just unpack a tar.gz archive with source code (or any archive with lots of small files), on my Linux client onto a NFS mounted disk to the OpenSolaris server, it's extremely slow compared to unpacking this archive on the locally on the server. A 22MB .tar.gz file containng 7360 files takes 9 minutes and 12seconds to unpack over NFS. Unpacking the same file locally on the server is just under 2 seconds. Between the server and client I have a gigabit network, which at the time of testing had no other significant load. My NFS mount options are: rw,hard,intr,nfsvers=3,tcp,sec=sys. Any suggestions to why this is? Regards, Sigbjorn ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss as someone else said, adding an ssd log device can help hugely. I saw about a 500% nfs write increase by doing this. I've heard of people getting even more. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
Thomas Burgess wrote: On Fri, Jul 23, 2010 at 3:11 AM, Sigbjorn Lie sigbj...@nixtra.com mailto:sigbj...@nixtra.com wrote: Hi, I've been searching around on the Internet to fine some help with this, but have been unsuccessfull so far. I have some performance issues with my file server. I have an OpenSolaris server with a Pentium D 3GHz CPU, 4GB of memory, and a RAIDZ1 over 4 x Seagate (ST31500341AS) 1,5TB SATA drives. If I compile or even just unpack a tar.gz archive with source code (or any archive with lots of small files), on my Linux client onto a NFS mounted disk to the OpenSolaris server, it's extremely slow compared to unpacking this archive on the locally on the server. A 22MB .tar.gz file containng 7360 files takes 9 minutes and 12seconds to unpack over NFS. Unpacking the same file locally on the server is just under 2 seconds. Between the server and client I have a gigabit network, which at the time of testing had no other significant load. My NFS mount options are: rw,hard,intr,nfsvers=3,tcp,sec=sys. Any suggestions to why this is? Regards, Sigbjorn as someone else said, adding an ssd log device can help hugely. I saw about a 500% nfs write increase by doing this. I've heard of people getting even more. Another option if you don't care quite so much about data security in the event of an unexpected system outage would be to use Robert Milkowski and Neil Perrin's zil synchronicity [PSARC/2010/108] changes with sync=disabled, when the changes work their way into an available build. The risk is that if the file server goes down unexpectedly, it might come back up having lost some seconds worth of changes which it told the client (lied) that it had committed to disk, when it hadn't, and this violates the NFS protocol. That might be OK if you are using it to hold source that's being built, where you can kick off a build again if the server did go down in the middle of it. Wouldn't be a good idea for some other applications though (although Linux ran this way for many years, seemingly without many complaints). Note that there's no increased risk of the zpool going bad - it's just that after the reboot, filesystems with sync=disabled will look like they were rewound by some seconds (possibly up to 30 seconds). -- Andrew Gabriel ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
I agree, I get apalling NFS speeds compared to CIFS/Samba..ie. CIFS/Samba of 95-105MB and NFS of 5-20MB. Not the thread hijack, but I assume a SSD ZIL will similarly improve an iSCSI target...as I am getting 2-5MB on that too. -- 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] NFS performance?
On 23 Jul 2010, at 09:18, Andrew Gabriel andrew.gabr...@oracle.com wrote: Thomas Burgess wrote: On Fri, Jul 23, 2010 at 3:11 AM, Sigbjorn Lie sigbj...@nixtra.com mailto:sigbj...@nixtra.com wrote: Hi, I've been searching around on the Internet to fine some help with this, but have been unsuccessfull so far. I have some performance issues with my file server. I have an OpenSolaris server with a Pentium D 3GHz CPU, 4GB of memory, and a RAIDZ1 over 4 x Seagate (ST31500341AS) 1,5TB SATA drives. If I compile or even just unpack a tar.gz archive with source code (or any archive with lots of small files), on my Linux client onto a NFS mounted disk to the OpenSolaris server, it's extremely slow compared to unpacking this archive on the locally on the server. A 22MB .tar.gz file containng 7360 files takes 9 minutes and 12seconds to unpack over NFS. Unpacking the same file locally on the server is just under 2 seconds. Between the server and client I have a gigabit network, which at the time of testing had no other significant load. My NFS mount options are: rw,hard,intr,nfsvers=3,tcp,sec=sys. Any suggestions to why this is? Regards, Sigbjorn as someone else said, adding an ssd log device can help hugely. I saw about a 500% nfs write increase by doing this. I've heard of people getting even more. Another option if you don't care quite so much about data security in the event of an unexpected system outage would be to use Robert Milkowski and Neil Perrin's zil synchronicity [PSARC/2010/108] changes with sync=disabled, when the changes work their way into an available build. The risk is that if the file server goes down unexpectedly, it might come back up having lost some seconds worth of changes which it told the client (lied) that it had committed to disk, when it hadn't, and this violates the NFS protocol. That might be OK if you are using it to hold source that's being built, where you can kick off a build again if the server did go down in the middle of it. Wouldn't be a good idea for some other applications though (although Linux ran this way for many years, seemingly without many complaints). Note that there's no increased risk of the zpool going bad - it's just that after the reboot, filesystems with sync=disabled will look like they were rewound by some secon ds (possibly up to 30 seconds). That's assuming you know it happened and that you need to restart the build (ideally with a make clean). All the NFS client knows is that the NFS server went away for some time. It still assumes nothing was lost. I can imagine cases where the build might continue to completion but with partially corrupted files. It's unlikely, but conceivable. Of course, databases like dbm, MySQL or Oracle would go blithely on up the swanee with silent data corruption. The fact that people run unsafe systems seemingly without complaint for years assumes that they know silent data corruption when they see^H^H^Hhear it ... which, of course, they didn't ... because it is silent ... or having encountered corrupted data, that they have the faintest idea where it came from. In my day to day work I still find many people that have been (apparently) very lucky. Feel free to play fast and loose with your own data, but I won't with mine, thanks! ;) ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
I see I have already received several replies, thanks to all! I would not like to risk losing any data, so I believe a ZIL device would be the way for me. I see these exists in different prices. Any reason why I would not buy a cheap one? Like the Intel X25-V SSD 40GB 2,5? What size of ZIL device would be recommened for my pool consisting for 4 x 1,5TB drives? Any brands I should stay away from? Regards, Sigbjorn On Fri, July 23, 2010 09:48, Phil Harman wrote: That's because NFS adds synchronous writes to the mix (e.g. the client needs to know certain transactions made it to nonvolatile storage in case the server restarts etc). The simplest safe solution, although not cheap, is to add an SSD log device to the pool. On 23 Jul 2010, at 08:11, Sigbjorn Lie sigbj...@nixtra.com wrote: Hi, I've been searching around on the Internet to fine some help with this, but have been unsuccessfull so far. I have some performance issues with my file server. I have an OpenSolaris server with a Pentium D 3GHz CPU, 4GB of memory, and a RAIDZ1 over 4 x Seagate (ST31500341AS) 1,5TB SATA drives. If I compile or even just unpack a tar.gz archive with source code (or any archive with lots of small files), on my Linux client onto a NFS mounted disk to the OpenSolaris server, it's extremely slow compared to unpacking this archive on the locally on the server. A 22MB .tar.gz file containng 7360 files takes 9 minutes and 12seconds to unpack over NFS. Unpacking the same file locally on the server is just under 2 seconds. Between the server and client I have a gigabit network, which at the time of testing had no other significant load. My NFS mount options are: rw,hard,intr,nfsvers=3,tcp,sec=sys. Any suggestions to why this is? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
On Fri, July 23, 2010 10:42, tomwaters wrote: I agree, I get apalling NFS speeds compared to CIFS/Samba..ie. CIFS/Samba of 95-105MB and NFS of 5-20MB. Not the thread hijack, but I assume a SSD ZIL will similarly improve an iSCSI target...as I am getting 2-5MB on that too. -- This message posted from opensolaris.org This is exactly the numbers I'm getting as well. What's the reason for such low rate when using iSCSI? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
Sent from my iPhone On 23 Jul 2010, at 09:42, tomwaters tomwat...@chadmail.com wrote: I agree, I get apalling NFS speeds compared to CIFS/Samba..ie. CIFS/Samba of 95-105MB and NFS of 5-20MB. Not the thread hijack, but I assume a SSD ZIL will similarly improve an iSCSI target...as I am getting 2-5MB on that too. Yes, it generally will. I've seen some huge improvements with iSCSI, but YMMV depending on your config, application and workload. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
On 23/07/2010 10:02, Sigbjorn Lie wrote: On Fri, July 23, 2010 10:42, tomwaters wrote: I agree, I get apalling NFS speeds compared to CIFS/Samba..ie. CIFS/Samba of 95-105MB and NFS of 5-20MB. Not the thread hijack, but I assume a SSD ZIL will similarly improve an iSCSI target...as I am getting 2-5MB on that too. -- This message posted from opensolaris.org This is exactly the numbers I'm getting as well. What's the reason for such low rate when using iSCSI? The filesystem or application using the iSCSI target may be requesting regular cache flushes. These will require synchronous writes to disk. An SSD doesn't remove the sync writes, it just makes them a lot faster. Other sensible storage servers typically use NVRAM caches to solve this problem. Others just play fast and loose with your data. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
On Fri, Jul 23, 2010 at 5:00 AM, Sigbjorn Lie sigbj...@nixtra.com wrote: I see I have already received several replies, thanks to all! I would not like to risk losing any data, so I believe a ZIL device would be the way for me. I see these exists in different prices. Any reason why I would not buy a cheap one? Like the Intel X25-V SSD 40GB 2,5? What size of ZIL device would be recommened for my pool consisting for 4 x 1,5TB drives? Any brands I should stay away from? Regards, Sigbjorn Like i said, i bought a 50 gb OCZ Vertex Limited Edition...it's like 200 dollars, up to 15,000 random iops (iops is what you want for fast zil) I've gotten excelent performance out of it. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] physically removed a pool - how to I tell it to forget the pool?
Hi guys, I physically removed disks from a pool without offlining the pool first...(yes I know) anyway I now want to delete/destroy the pool...but zpool destroy -f dvr says can not open 'dvr':no such pool I can not offline it or delete it! I want to reuse the name dvr but how do I do this? ie. how do I totally delete a pool who's disks have been physically removed? -- 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] physically removed a pool - how to I tell it to forget the pool?
If all disks were actually removed, renaming /etc/zfs/zpool.cache and rebooting should do the trick. I am not sure but you may have to import root pool at next reboot. F. tomwaters wrote: Hi guys, I physically removed disks from a pool without offlining the pool first...(yes I know) anyway I now want to delete/destroy the pool...but zpool destroy -f dvr says can not open 'dvr':no such pool I can not offline it or delete it! I want to reuse the name dvr but how do I do this? ie. how do I totally delete a pool who's disks have been physically removed? -- Oracle Global Customer Services Francois Napoleoni / TSC Engineer Solaris Networking, Global Systems Support Email : francois.napole...@oracle.com Phone : +33 (0)1 34 03 17 07 Fax : +33 (0)1 34 03 11 14 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Increase resilver priority
Hello, We've seen some resilvers on idle servers that are taking ages. Is it possible to speed up resilver operations somehow? Eg. iostat shows 5MB/s writes on the replaced disks. I'm thinking a small performance degradation would be sometimes better than the increased risk window (where a vdev is degraded). Thank you, -- Giovanni Tirloni gtirl...@sysdroid.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
On Fri, July 23, 2010 11:21, Thomas Burgess wrote: On Fri, Jul 23, 2010 at 5:00 AM, Sigbjorn Lie sigbj...@nixtra.com wrote: I see I have already received several replies, thanks to all! I would not like to risk losing any data, so I believe a ZIL device would be the way for me. I see these exists in different prices. Any reason why I would not buy a cheap one? Like the Intel X25-V SSD 40GB 2,5? What size of ZIL device would be recommened for my pool consisting for 4 x 1,5TB drives? Any brands I should stay away from? Regards, Sigbjorn Like i said, i bought a 50 gb OCZ Vertex Limited Edition...it's like 200 dollars, up to 15,000 random iops (iops is what you want for fast zil) I've gotten excelent performance out of it. The X25-V has up to 25k random read iops and up to 2.5k random write iops per second, so that would seem okay for approx $80. :) What about mirroring? Do I need mirrored ZIL devices in case of a power outage? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
On 23/07/2010 10:53, Sigbjorn Lie wrote: The X25-V has up to 25k random read iops and up to 2.5k random write iops per second, so that would seem okay for approx $80. :) What about mirroring? Do I need mirrored ZIL devices in case of a power outage? Note there is not a ZIL device, there is a slog device. Every pool has one or more ZIL it may or may not have a slog device used to hold ZIL contents, wither a ZIL is on the slog or not depends on a lot of factors including the logbias property. You don't need to mirror the slog device to protect against a power outage. You need to mirror the slog if you want to protect against loosing synchronous writes (but not pool consistency on disk) on power outage *and* failure of your slog device at the same time (ie a double fault). -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] physically removed a pool - how to I tell it to forget the pool?
It was fine on the reboot...so even though zfs destroy threw up the errors, it did remove them...just needed a reboot to refresh/remove it in the zpool list. 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 raidz1 and traditional raid 5 perfomrance comparision
From: Robert Milkowski [mailto:mi...@task.gda.pl] [In raidz] The issue is that each zfs filesystem block is basically spread across n-1 devices. So every time you want to read back a single fs block you need to wait for all n-1 devices to provide you with a part of it - and keep in mind in zfs you can't get a partial block even if that's what you are asking for as zfs has to check checksum of entire fs block. Can anyone else confirm or deny the correctness of this statement? If you read a small file from a raidz volume, do you have to wait for every single disk to return a small chunk of the blocksize? I know this is true for large files which require more than one block, obviously, but even a small file gets spread out across multiple disks? This may be the way it's currently implemented, but it's not a mathematical requirement. It is possible, if desired, to implement raid parity and still allow small files to be written entirely on a single disk, without losing redundancy. Thus providing the redundancy, the large file performance, (both of which are already present in raidz), and also optimizing small file random operations, which may not already be optimized in raidz. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Phil Harman Milkowski and Neil Perrin's zil synchronicity [PSARC/2010/108] changes with sync=disabled, when the changes work their way into an available The fact that people run unsafe systems seemingly without complaint for years assumes that they know silent data corruption when they see^H^H^Hhear it ... which, of course, they didn't ... because it is silent ... or having encountered corrupted data, that they have the faintest idea where it came from. In my day to day work I still find many people that have been (apparently) very lucky. Running with sync disabled, or ZIL disabled, you could call unsafe if you want to use a generalization and a stereotype. Just like people say writeback is unsafe. If you apply a little more intelligence, you'll know, it's safe in some conditions, and not in other conditions. Like ... If you have a BBU, you can use your writeback safely. And if you're not sharing stuff across the network, you're guaranteed the disabled ZIL is safe. But even when you are sharing stuff across the network, the disabled ZIL can still be safe under the following conditions: If you are only doing file sharing (NFS, CIFS) and you are willing to reboot/remount from all your clients after an ungraceful shutdown of your server, then it's safe to run with ZIL disabled. If you're unsure, then adding SSD nonvolatile log device, as people have said, is the way to go. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Sigbjorn Lie What size of ZIL device would be recommened for my pool consisting for Get the smallest one. Even an unrealistic high performance scenario cannot come close to using 32G. I am sure you'll never reach even 4G usage. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Sigbjorn Lie What about mirroring? Do I need mirrored ZIL devices in case of a power outage? You don't need mirroring for the sake of *power outage* but you *do* need mirroring for the sake of preventing data loss when one of the SSD devices fails. There is some gray area here: If you have zpool 19, then you do not have log device removal which means you lose your whole zpool in the event of a failed unmirrored log device. (Techniques exist to recover, but it's not always easy.) If you have zpool = 19, then the danger is much smaller. If you have a failed unmirrored log device, and the failure is detected, then the log device is simply marked failed and the system slows down, and everything is fine. But if you have an undetected failure, *and* an ungraceful reboot (which is more likely than it seems) then you risk up to 30 sec of data that was intended to be written, immediately before the crash. None of that is a concern, if you have a mirrored log device. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
Edward Ned Harvey wrote: From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Phil Harman Milkowski and Neil Perrin's zil synchronicity [PSARC/2010/108] changes with sync=disabled, when the changes work their way into an available The fact that people run unsafe systems seemingly without complaint for years assumes that they know silent data corruption when they see^H^H^Hhear it ... which, of course, they didn't ... because it is silent ... or having encountered corrupted data, that they have the faintest idea where it came from. In my day to day work I still find many people that have been (apparently) very lucky. Running with sync disabled, or ZIL disabled, you could call unsafe if you want to use a generalization and a stereotype. Just like people say writeback is unsafe. If you apply a little more intelligence, you'll know, it's safe in some conditions, and not in other conditions. Like ... If you have a BBU, you can use your writeback safely. And if you're not sharing stuff across the network, you're guaranteed the disabled ZIL is safe. But even when you are sharing stuff across the network, the disabled ZIL can still be safe under the following conditions: If you are only doing file sharing (NFS, CIFS) and you are willing to reboot/remount from all your clients after an ungraceful shutdown of your server, then it's safe to run with ZIL disabled. No, that's not safe. The client can still lose up to 30 seconds of data, which could be, for example, an email message which is received and foldered on the server, and is then lost. It's probably /*safe enough*/ for most home users, but you should be fully aware of the potential implications before embarking on this route. (As I said before, the zpool itself is not at any additional risk of corruption, it's just that you might find the zfs filesystems with sync=disabled appear to have been rewound by up to 30 seconds.) If you're unsure, then adding SSD nonvolatile log device, as people have said, is the way to go. -- Andrew Gabriel ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs raidz1 and traditional raid 5 perfomrance comparision
Edward Ned Harvey wrote: From: Robert Milkowski [mailto:mi...@task.gda.pl] [In raidz] The issue is that each zfs filesystem block is basically spread across n-1 devices. So every time you want to read back a single fs block you need to wait for all n-1 devices to provide you with a part of it - and keep in mind in zfs you can't get a partial block even if that's what you are asking for as zfs has to check checksum of entire fs block. Can anyone else confirm or deny the correctness of this statement? If you read a small file from a raidz volume, do you have to wait for every single disk to return a small chunk of the blocksize? I know this is true for large files which require more than one block, obviously, but even a small file gets spread out across multiple disks? This may be the way it's currently implemented, but it's not a mathematical requirement. It is possible, if desired, to implement raid parity and still allow small files to be written entirely on a single disk, without losing redundancy. Thus providing the redundancy, the large file performance, (both of which are already present in raidz), and also optimizing small file random operations, which may not already be optimized in raidz. As I understand it that's the whole point of raidz. Each block is its own stripe. If necessary the block gets broken down into 512 byte chunks to spread it as wide as possible. Each block gets its own parity added. So if the array is too wide for the block to be spread to all disks, you also lose space because the stripe is not full and parity gets added to that small stripe. That means if you only write 512 byte blocks, each write writes 3 blocks to disk, so the net capacity goes down to one third, regardless how many disks you have in your raid group. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs add -r output
Hi Ryan, You are seeing this CR: http://bugs.opensolaris.org/view_bug.do?bug_id=6916574 zpool add -n displays incorrect structure This is a display problem only. Thanks, Cindy On 07/22/10 15:54, Ryan Schwartz wrote: I've got a system running s10x_u7wos_08 with only half of the disks provisioned. When performing a dry run of a zpool add, I'm seeing some strange output: root# zpool add -n vst raidz2 c0t2d0 c5t1d0 c4t1d0 c4t5d0 c7t1d0 c7t5d0 c6t1d0 c6t5d0 c1t1d0 c1t5d0 c0t1d0 raidz2 c0t5d0 c0t5d0 c4t4d0 c7t0d0 c7t4d0 c6t0d0 c6t4d0 c1t0d0 c1t4d0 c0t0d0 c0t4d0 would update 'vst' to the following configuration: vst raidz2 c5t3d0 c5t7d0 c4t3d0 c4t7d0 c7t3d0 c7t7d0 c6t3d0 c6t7d0 c1t3d0 c1t7d0 c0t3d0 raidz2 c0t7d0 c5t2d0 c5t6d0 c4t2d0 c4t6d0 c7t2d0 c7t6d0 c6t2d0 c6t6d0 c1t2d0 c1t6d0 raidz2 c0t2 c5t1 c4t1 c4t5 c7t1 c7t5 c6t1 c6t5 c1t1 c1t5 c0t1 raidz2 c0t5 c0t5 c4t4 c7t0 c7t4 c6t0 c6t4 c1t0 c1t4 c0t0 c0t4 I would expect the new configuration would use the full shorthand device names, including the d0. Is this normal/expected output for a system on s10x_u7wos_08? Thanks, ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
Phil Harmon wrote: Not the thread hijack, but I assume a SSD ZIL will similarly improve an iSCSI target...as I am getting 2-5MB on that too. Yes, it generally will. I've seen some huge improvements with iSCSI, but YMMV depending on your config, application and workload. Sorry this isn't completely ZFS-related, but with all this expert storage knowledge here... On a related note - all other things being equal, is there any reason to choose NFS over ISCI, or vice-versa? I'm currently looking at this decision. We have a NetApp (I wish it were a ZFS-based appliance!) and need to remotely mount a filesystem from it. It will share the filesystem either as NFS or ICSI. Some of my colleagues say it would be better to use NFS. Their reasoning is basically: That's the way it's always been done. I'm leaning towards ISCSI. My reasoning is that it removes a whole extra layer of complexity - as I understand it, the remote client just treats the remote mount like any other physical device. And I've had MAJOR headaches over the years fixing/tweaking NFS. Even though version 4 seems better, I'd still rather bypass it completely. I believe in the Keep it simple, stupid philosophy. I do realize that NFS is probably better for remote filesystems that have multiple simultaneous users, but we won't be doing that in this case. Any major arguments for/against one over the other? Thanks for any suggestions. Doug Linder -- Learn more about Merchant Link at www.merchantlink.com. THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information intended only for the use of the recipient(s) named above. If you are not the intended recipient, you may not print, distribute, or copy this message or any attachments. If you have received this communication in error, please notify the sender by return e-mail and delete this message and any attachments from your computer. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Increase resilver priority
On Jul 23, 2010, at 2:31 AM, Giovanni Tirloni wrote: Hello, We've seen some resilvers on idle servers that are taking ages. Is it possible to speed up resilver operations somehow? Eg. iostat shows 5MB/s writes on the replaced disks. This is lower than I expect, but It may be IOPS bound. What does iostat say about the IOPS and asvc_t ? -- richard -- Richard Elling rich...@nexenta.com +1-760-896-4422 Enterprise class storage for everyone www.nexenta.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Increase resilver priority
On 07/23/10 02:31, Giovanni Tirloni wrote: We've seen some resilvers on idle servers that are taking ages. Is it possible to speed up resilver operations somehow? Eg. iostat shows5MB/s writes on the replaced disks. What build of opensolaris are you running? There were some recent improvements (notably the addition of prefetch to the pool traverse used by scrub and resilver) which sped this up significantly for my systems. Also: if there are large numbers of snapshots, pools seem to take longer to resilver, particularly when there's a lot of metadata divergence between snapshots. Turning off atime updates (if you and your applications can cope with this) may also help going forward. - Bill ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Increase resilver priority
On Fri, Jul 23, 2010 at 11:59 AM, Richard Elling rich...@nexenta.com wrote: On Jul 23, 2010, at 2:31 AM, Giovanni Tirloni wrote: Hello, We've seen some resilvers on idle servers that are taking ages. Is it possible to speed up resilver operations somehow? Eg. iostat shows 5MB/s writes on the replaced disks. This is lower than I expect, but It may be IOPS bound. What does iostat say about the IOPS and asvc_t ? -- richard It seems to have improved a bit. scrub: resilver in progress for 7h19m, 75.37% done, 2h23m to go config: NAME STATE READ WRITE CKSUM storage DEGRADED 0 1 0 mirror DEGRADED 0 0 0 c3t2d0ONLINE 0 0 0 replacing DEGRADED 1.29M 0 0 c3t3d0s0/o FAULTED 0 0 0 corrupted data c3t3d0 DEGRADED 0 0 1.29M too many errors mirror ONLINE 0 0 0 c3t4d0ONLINE 0 0 0 c3t5d0ONLINE 0 0 0 mirror DEGRADED 0 0 0 c3t6d0ONLINE 0 0 0 c3t7d0REMOVED 0 0 0 mirror ONLINE 0 0 0 c3t8d0ONLINE 0 0 0 c3t9d0ONLINE 0 0 0 mirror ONLINE 0 0 0 c3t10d0 ONLINE 0 0 0 c3t11d0 ONLINE 0 0 0 mirror ONLINE 0 0 0 c3t12d0 ONLINE 0 0 0 c3t13d0 ONLINE 0 0 0 mirror ONLINE 0 0 0 c3t14d0 ONLINE 0 0 0 c3t15d0 ONLINE 0 0 0 mirror ONLINE 0 0 0 c3t16d0 ONLINE 0 0 0 c3t17d0 ONLINE 0 0 0 mirror ONLINE 0 0 0 c3t18d0 ONLINE 0 0 0 c3t19d0 ONLINE 0 0 0 mirror ONLINE 0 0 0 c3t20d0 ONLINE 0 0 0 c3t21d0 ONLINE 0 0 0 logs DEGRADED 0 1 0 mirror ONLINE 0 0 0 c3t1d0ONLINE 0 0 0 c3t22d0 ONLINE 0 0 0 extended device statistics r/sw/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 582.2 864.3 68925.2 37511.2 0.0 52.70.0 36.4 0 610 c3 0.0 201.70.0 806.7 0.0 0.00.00.1 0 2 c3t0d0 0.0 268.20.0 10531.2 0.0 0.10.00.4 0 10 c3t1d0 144.10.0 18375.90.0 0.0 9.50.0 65.7 0 100 c3t2d0 79.5 125.2 10109.9 15634.3 0.0 35.00.0 171.0 0 100 c3t3d0 10.90.0 1181.30.0 0.0 0.10.0 13.3 0 10 c3t4d0 19.90.0 2120.60.0 0.0 0.30.0 15.6 0 19 c3t5d0 35.80.0 3819.50.0 0.0 0.60.0 18.1 0 28 c3t6d0 0.00.00.00.0 0.0 0.00.00.0 0 0 c3t7d0 22.90.0 2506.60.0 0.0 0.50.0 22.0 0 22 c3t8d0 15.90.0 1639.80.0 0.0 0.30.0 20.5 0 15 c3t9d0 23.80.0 2889.60.0 0.0 0.50.0 19.8 0 27 c3t10d0 21.90.0 2558.30.0 0.0 0.60.0 28.9 0 19 c3t11d0 32.80.0 3151.90.0 0.0 1.20.0 37.4 0 25 c3t12d0 25.80.0 2707.80.0 0.0 0.50.0 18.8 0 26 c3t13d0 19.90.0 2281.10.0 0.0 0.30.0 17.5 0 24 c3t14d0 23.80.0 2782.30.0 0.0 0.30.0 14.6 0 20 c3t15d0 18.90.0 2249.80.0 0.0 0.40.0 19.7 0 23 c3t16d0 21.90.0 2519.50.0 0.0 0.50.0 22.6 0 27 c3t17d0 12.90.0 1653.20.0 0.0 0.20.0 16.8 0 18 c3t18d0 26.80.0 3262.70.0 0.0 0.80.0 28.4 0 29 c3t19d0 9.90.0 1271.70.0 0.0 0.10.0 14.3 0 13 c3t20d0 14.90.0 1843.90.0 0.0 0.30.0 20.5 0 19 c3t21d0 0.0 269.20.0 10539.0 0.0 0.40.01.3 0 33 c3t22d0 extended device statistics r/sw/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 405.1 745.2 51057.2 29893.8 0.0 53.30.0 46.4 0 457 c3 0.0 252.10.0 1008.3 0.0 0.00.00.1 0 2 c3t0d0 0.0 177.10.0 5485.8 0.0 0.00.00.3 0 4 c3t1d0 145.00.0 18438.00.0 0.0 15.10.0 104.0 0 100 c3t2d0 80.0 140.0 10147.8 17925.9 0.0 35.00.0 159.0 0 100 c3t3d0 8.00.0 1024.30.0 0.0 0.20.0 19.9 0 12 c3t4d0 7.00.0 768.30.0 0.0 0.10.0 15.5 0 11 c3t5d0 24.00.0 3009.00.0 0.0 0.50.0
Re: [zfs-discuss] Increase resilver priority
On Fri, Jul 23, 2010 at 12:50 PM, Bill Sommerfeld bill.sommerf...@oracle.com wrote: On 07/23/10 02:31, Giovanni Tirloni wrote: We've seen some resilvers on idle servers that are taking ages. Is it possible to speed up resilver operations somehow? Eg. iostat shows5MB/s writes on the replaced disks. What build of opensolaris are you running? There were some recent improvements (notably the addition of prefetch to the pool traverse used by scrub and resilver) which sped this up significantly for my systems. b111. Thanks for the heads up regarding these improvements, I'll try that in b134. Also: if there are large numbers of snapshots, pools seem to take longer to resilver, particularly when there's a lot of metadata divergence between snapshots. Turning off atime updates (if you and your applications can cope with this) may also help going forward. There are 7 snapshots and atime is disabled. -- Giovanni Tirloni gtirl...@sysdroid.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Random system hang build 134
Symptoms: 1. System remains pingable 2. When trying to ssh in terminal hangs after entering pass 3. At the console terminal hangs after entering pass 4. Problem persists after disabling snapshots/compression/dedup Solution: Hard reboot (A+F1 does not work) Configuration: Supermicro Mobo 24 x 2TB WD Black Drives (2 x 12 drive in RAIDZ2) Mirrored OCZ 32GB SSD drives for OS (ZFS mirrored rpool) Mirrored Intel extreme 64GB drives (ZIL) Quad Port Intel Gb NIC - aggr1 12GB DDR3 Does anyone have any idea what the problem could be or how I can track this down? Just so that you know I have 2 of these system with identical setup and hardware so I have excluded the possibility that this could be a bad piece of hardware. -- 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 volume turned into a socket - any way to restore data?
On Jul 23, 2010, at 9:10 AM, Ruslan Sivak wrote: I have recently upgraded from NexentaStor 2 to NexentaStor 3 and somehow one of my volumes got corrupted. Its showing up as a socket. Has anyone seen this before? Is there a way to get my data back? It seems like it's still there, but not recognized as a folder. I ran zpool scrub, but it came back clean. very strange indeed. Attached is the output of #zdb data/rt 2.0K sr-xr-xr-x 17 root root 17 Jul 21 17:43 rt # stat rt File: `rt' Size: 17 Blocks: 4 IO Block: 1536 socket Device: 2d90015h/47775765d Inode: 3 Links: 17 Access: (0555/sr-xr-xr-x) Uid: (0/root) Gid: (0/root) Access: 2010-07-21 13:48:09.485116161 -0400 Modify: 2010-07-21 17:43:13.019153434 -0400 Change: 2010-07-22 15:50:06.222143953 -0400 # cd rt bash: cd: rt: Not a directory # cat rt cat: rt: Operation not supported on transport endpoint a# zfs list NAME USED AVAIL REFER MOUNTPOINT data 992G 828G 47.8K /volumes/data ... data/rt 800G 828G 800G /volumes/data/rt data/rt20 828G 800G /volumes/data/rt2 syspool 6.31G 23.0G 35.5K legacy syspool/dump2.79G 23.0G 2.79G - syspool/rootfs-nmu-000 115M 23.0G 1.32G legacy syspool/rootfs-nmu-001 1.59G 23.0G 1.17G legacy syspool/rootfs-nmu-002 793M 23.0G 1.17G legacy syspool/swap1.03G 24.0G16K - # zfs umount data/rt #ls -lahs ... 2.0K drwxr-xr-x 2 root root 2 Jul 22 16:48 rt 2.0K srwxr-xr-x 17 root root 17 Jul 21 17:43 rt2 If at this point data/rt is unmounted, then: mv rt2 rt2-bad zfs mount data/rt -- richard ... -- This message posted from opensolaris.orgzdb.zip___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Richard Elling rich...@nexenta.com +1-760-896-4422 Enterprise class storage for everyone www.nexenta.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Confused about consumer drives and zfs can someone help?
On 7/23/2010 3:39 AM, tomwaters wrote: There is alot there to reply to...but I will try and help... Re. TLER. Do not worry about TLER when using ZFS. ZFS will handle it either way and will NOT time out and drop the drive...it may wait a long time, but it will not time out and drop the drive - nor will it have an issue if you do enable TLER-ON (which sets time out to 7 seonds). I run both with TLER-ON (disks from an old mdadm raid array) and without (TLER-OFF) 1.5TB WDEADS. That's reassuring. I guess the only time the issue will come up is when the drive starts to develop errors. I can not speak for the WD EARS, but the WDEADS are fine in my home nas. I also run 1.5TB Samsung Green/Silencer series and Seagate 11's. Others swear by Hitachi. I would recommend the Samsung or Hitachi and not the new WD EARS which have that 4k sectors or whatever it is. I've been digging through the archives more and I'm starting to lean towards laptop drives. I found this discussion http://opensolaris.org/jive/message.jspa?messageID=468269#468269 and contacted someone else who has used 3 WD Scorpio Black drives in a 3 way mirror for a year without any problems. This is mostly going to be a backup server so I'm not too worried about performance. Re the CPU, do not go low power Atom etc, go a newish Core2 duo...the power differential at idle is bugger all and when you want to use the nas, ZFS will make good use of the CPU. Honestly, sit down and do the calculations on power savings of a low power cpu and you'll see it's better to just not have that 5th beer on a friday - you'll save more money that way and be MUCH happier with your nas performance. re. cards...I use and recommend these 8-Port SUPERMICRO AOC-USASLP-L8I UIO SAS. They are cheap on e-bay, just work and are fast. Use them. You do want alot of ram I use 8GB, but you can use 4. Ram is cheap, ZFS loves ram, just buy 8. IMHO (and that of the best practice guide) - you should mirror the rpool (o/s disk). Just buy 2 cheap laptop drives and when installing choose to mirror them. I can find some motherboards with 4-6 onboard sata ports. If I go with 2 USB flash drives for a mirrored rpool do you think that would be ok? Performance seems to be about the same as 5400 rpm laptop drives. I hope that helps. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] snapshot .zfs folder can only be seen in the top of a file system?
Hi, Is it true? Any way to find it in every hierarchy? Thanks. Fred ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs raidz1 and traditional raid 5 perfomrance comparision
From: Arne Jansen [mailto:sensi...@gmx.net] Can anyone else confirm or deny the correctness of this statement? As I understand it that's the whole point of raidz. Each block is its own stripe. Nope, that doesn't count for confirmation. It is at least theoretically possible to implement raidz using techniques that would (a) unintelligently stripe all blocks (even small ones) across multiple disks, thus hurting performance on small operations, or (b) implement raidz such that striping of blocks behaves differently for small operations (plus parity). So the confirmation I'm looking for would be somebody who knows the actual source code, and the actual architecture that was chosen to implement raidz in this case. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Linder, Doug On a related note - all other things being equal, is there any reason to choose NFS over ISCI, or vice-versa? I'm currently looking at this iscsi and NFS are completely different technologies. If you use iscsi, then all the initiators (clients) are the things which format and control the filesystem. So the limitations of the filesystem are determined by whichever clustering filesystem you've chosen to implement. It probably won't do snapshots and so forth. Although the ZFS filesystem could make a snapshot, it wouldn't be automatically mounted or made available without the clients doing explicit mounts... With NFS, the filesystem is formatted and controlled by the server. Both WAFL and ZFS do some pretty good things with snapshotting, and making snapshots available to users without any effort. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] snapshot .zfs folder can only be seen in the top of a file system?
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Fred Liu Is it true? Any way to find it in every hierarchy? Yup. Nope. If you use ZFS, you make a filesystem at whatever level you need it, in order for the .zfs directory to be available to whatever clients will be needing it... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] snapshot .zfs folder can only be seen in the top of a file system?
Thanks. But too many file systems may be an issue for management and also normal user cannot create file system. I think it should go like what NetApp's snapshot does. It is a pity. Thanks. Fred -Original Message- From: Edward Ned Harvey [mailto:sh...@nedharvey.com] Sent: 星期六, 七月 24, 2010 10:22 To: Fred Liu; zfs-discuss@opensolaris.org Subject: RE: [zfs-discuss] snapshot .zfs folder can only be seen in the top of a file system? From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Fred Liu Is it true? Any way to find it in every hierarchy? Yup. Nope. If you use ZFS, you make a filesystem at whatever level you need it, in order for the .zfs directory to be available to whatever clients will be needing it... ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] NFS performance?
Fundamentally, my recommendation is to choose NFS if your clients can use it. You'll get a lot of potential advantages in the NFS/zfs integration, so better performance. Plus you can serve multiple clients, etc. The only reason to use iSCSI is when you don't have a choice, IMO. You should only use iSCSI with a single initiator at any point in time unless you have some higher level contention management in place. - Garrett On Fri, 2010-07-23 at 22:20 -0400, Edward Ned Harvey wrote: From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Linder, Doug On a related note - all other things being equal, is there any reason to choose NFS over ISCI, or vice-versa? I'm currently looking at this iscsi and NFS are completely different technologies. If you use iscsi, then all the initiators (clients) are the things which format and control the filesystem. So the limitations of the filesystem are determined by whichever clustering filesystem you've chosen to implement. It probably won't do snapshots and so forth. Although the ZFS filesystem could make a snapshot, it wouldn't be automatically mounted or made available without the clients doing explicit mounts... With NFS, the filesystem is formatted and controlled by the server. Both WAFL and ZFS do some pretty good things with snapshotting, and making snapshots available to users without any effort. ___ 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
Re: [zfs-discuss] snapshot .zfs folder can only be seen in the top of a file system?
On Jul 23, 2010, at 7:33 PM, Fred Liu fred_...@issi.com wrote: Thanks. But too many file systems may be an issue for management and also normal user cannot create file system. The ability to create or snapshot a file system can easily be delegated to a user. I think it should go like what NetApp's snapshot does. There was a long thread on this topic earlier this year. Please see the archives for details. It is a pity. Disagree. The benefits are not as great as advertised. -- Richard Thanks. Fred -Original Message- From: Edward Ned Harvey [mailto:sh...@nedharvey.com] Sent: 星期六, 七月 24, 2010 10:22 To: Fred Liu; zfs-discuss@opensolaris.org Subject: RE: [zfs-discuss] snapshot .zfs folder can only be seen in the top of a file system? From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Fred Liu Is it true? Any way to find it in every hierarchy? Yup. Nope. If you use ZFS, you make a filesystem at whatever level you need it, in order for the .zfs directory to be available to whatever clients will be needing it... ___ 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
Re: [zfs-discuss] snapshot .zfs folder can only be seen in the top of a file system?
I think it should go like what NetApp's snapshot does. There was a long thread on this topic earlier this year. Please see the archives for details. Do you have the URL? I don't have a long subscription I too do not have a long subscription, and I would be interested in the subject line so I can search and do further reading. -- Sam Fourman Jr. Fourman Networks http://www.fourmannetworks.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
