[zfs-discuss] metadata inconsistency?
Hi, after some unscheduled reboots (to put it lightly), I've got an interesting setup on my notebook's zfs partition: setup: simple zpool, no raid or mirror, a couple of zfs partitions, one zvol for swap. /foo is one such partition, /foo/bar the directory with the issue. directly after the reboot happened: $ ls /foo/bar test.h $ ls -l /foo/bar Total 0 the file wasn't accessible with cat, etc. somewhat later (new data appeared on /foo, in /foo/baz): $ ls -l /foo/bar Total 3 -rw-r--r-- 1 user group 1400 Jul 6 02:14 test.h the content of test.h is the same as the content of /foo/baz/quux now, but the refcount is 1! $ chmod go-r /foo/baz/quux $ ls -l /foo/bar Total 3 -rw--- 1 user group 1400 Jul 6 02:14 test.h good, so at least it's no security concern. anyway, how do I get rid of test.h now without making quux unreadable? (the brute force approach would be a new partition, moving data over with copying - instead of moving - the troublesome file, just in case - not sure if zfs allows for links that cross zfs partitions and thus optimizes such moves, then zfs destroy data/test, but there might be a better way?) patrick mauritz This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Most stupid Ten reasons not to use ZFS
Hello zfs-discuss, http://www.redhat.com/archives/fedora-list/2006-June/msg03623.html Are they so afraid they have to write such bullshit!? -- Best regards, Robert mailto:[EMAIL PROTECTED] http://milek.blogspot.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] x86 CPU Choice for ZFS
Hello, What kind of x86 CPU does ZFS prefer? In particular, what kind of CPU is optimal when using RAID-Z with a large number of disks (8)? Does L2 cache size play a big role, 256kb vs 512kb vs 1MB? Are there any performance improvements when using a dual core or quad processor machine? I am choosing a CPU in a system primarily for ZFS and am wondering whether paying the extra price for a larger cache or going dual core will provide any benefits. Or would it be better to put the money towards a higher clocked CPU? 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] x86 CPU Choice for ZFS
Siegfried Nikolaivich wrote: Hello, What kind of x86 CPU does ZFS prefer? In particular, what kind of CPU is optimal when using RAID-Z with a large number of disks (8)? My experience is that for hardware that will be used in a server orientated role, there are a lot of considerations that need to be taken into account in addition to MHz and cache sizes. But for ZFS, it has been said often that it currently performs much better with a 64bit address space, such as that with Opterons and other AMD64 CPUs. I think this would play a bigger part in a ZFS server performing well than just MHZ and cache size. Darren ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] x86 CPU Choice for ZFS
>Hello, > >What kind of x86 CPU does ZFS prefer? In particular, what kind of CPU is >optimal when using RAID-Z with a large number of disks (8)? > >Does L2 cache size play a big role, 256kb vs 512kb vs 1MB? Are there any >performance improvements when using a dual core or quad processor machine? The most important factor when selecting a CPU for ZFS is that is /must/ be a 64 bit CPU. It's very virtual memory hungry. (It works on 32 bit systems, but there are many limitations) Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Most stupid Ten reasons not to use ZFS
Robert Milkowski wrote: Hello zfs-discuss, http://www.redhat.com/archives/fedora-list/2006-June/msg03623.html Are they so afraid they have to write such bullshit!? The most annoying part to me is this bit: "2 . ZFS does not support the necessary extended attributes and ACLs to enable the implementation of SELinux security. Instead Sun prefers the deployment of its own security software "Trusted Solaris", which is not FOSS and runs at a cost of "$995 per seat for the Standard Edition Desktop System to $79,495 for the Certified Edition Data Center Server."" While that is true for Trusted Solaris 8 it is most certainly NOT true for Solaris Trusted Extensions. The only part of Trusted Extensions that is not currently under an OSI approved license is the modifications to CDE because we can't produce that. Whats more ZFS DOES have ACLs and DOES have extended attributes. SELinux is the new guy on the block, Trusted Solaris is older than all of Linux! The rest is just uninformed licensing related fud. More fool them for not getting it! -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] x86 CPU Choice for ZFS
Casper; Does this mean it would be a good practice to say increase the amount of memory and/or swap space we usually recommend if the customer intends to use ZFS very heavily? Sorry if this is a dumb question! Warmest Regards Steven Sim [EMAIL PROTECTED] wrote: Hello, What kind of x86 CPU does ZFS prefer? In particular, what kind of CPU is optimal when using RAID-Z with a large number of disks (8)? Does L2 cache size play a big role, 256kb vs 512kb vs 1MB? Are there any performance improvements when using a dual core or quad processor machine? The most important factor when selecting a CPU for ZFS is that is /must/ be a 64 bit CPU. It's very virtual memory hungry. (It works on 32 bit systems, but there are many limitations) Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss Fujitsu Asia Pte. Ltd. _ This e-mail is confidential and may also be privileged. If you are not the intended recipient, please notify us immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person. Opinions, conclusions and other information in this message that do not relate to the official business of my firm shall be understood as neither given nor endorsed by it. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Most stupid Ten reasons not to use ZFS
Darren J Moffat stated: < Robert Milkowski wrote: < >Hello zfs-discuss, < > < > http://www.redhat.com/archives/fedora-list/2006-June/msg03623.html < > < > Are they so afraid they have to write such bullshit!? < < The most annoying part to me is this bit: < < "2 . ZFS does not support the necessary extended attributes and ACLs to < enable the implementation of SELinux security. Instead Sun prefers the < deployment of its own security software "Trusted Solaris", which is < not FOSS and runs at a cost of "$995 per seat for the Standard Edition < Desktop System to $79,495 for the Certified Edition Data Center < Server."" < < While that is true for Trusted Solaris 8 it is most certainly NOT true < for Solaris Trusted Extensions. The only part of Trusted Extensions < that is not currently under an OSI approved license is the modifications < to CDE because we can't produce that. < < Whats more ZFS DOES have ACLs and DOES have extended attributes. < < SELinux is the new guy on the block, Trusted Solaris is older than all < of Linux! < < The rest is just uninformed licensing related fud. < < More fool them for not getting it! Some do, see this followup: http://www.redhat.com/archives/fedora-list/2006-June/msg04266.html This poster even corrects himself on the Trusted Solaris front with another follow up at: http://www.redhat.com/archives/fedora-list/2006-June/msg04497.html < < -- < Darren J Moffat < ___ < zfs-discuss mailing list < zfs-discuss@opensolaris.org < http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Sean. . ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] x86 CPU Choice for ZFS
Steven Sim wrote: Casper; Does this mean it would be a good practice to say increase the amount of memory and/or swap space we usually recommend if the customer intends to use ZFS very heavily? ZFS doesn't necessarily use more memory (physical or virtual) than UFS it needs more VM *address space* (not the same as more VM) hence the 64 bit processor. -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] x86 CPU Choice for ZFS
>Casper; > >Does this mean it would be a good practice to say increase the amount of >memory and/or swap space we usually recommend if the customer intends to >use ZFS very heavily? Memory is always good; but it is *virtual* memory (address space) which matters most. The 32 bit kernel only has a 1GB or so of address space (it's shared with userland); the 64 bit kernel has something closely resembling infinity Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Most stupid Ten reasons not to use ZFS
Darren J Moffat wrote: The rest is just uninformed licensing related fud. More fool them for not getting it! Indeed. There was a followup to that email that went through and debunked that posting along exactly those lines and to which the OP did not respond. Darren ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Most stupid Ten reasons not to use ZFS
Sean McGrath - Sun Microsystems Ireland wrote: Some do, see this followup: http://www.redhat.com/archives/fedora-list/2006-June/msg04266.html This poster even corrects himself on the Trusted Solaris front with another follow up at: http://www.redhat.com/archives/fedora-list/2006-June/msg04497.html And does so by pointing to *my* blog even, cool! -- Darren J Moffat ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: Supporting ~10K users on ZFS
Hi, does anybody successfully try the option sharenfs=on for an zfs filesystem with 1 users? On my system (sol10u2), that is not only awfully slow but does also not work smoothly. I did run the following commands: zpool create -R /test test c2t600C0FF00988193CD00CE701d0s0 zfs create test/home zfs set sharenfs=on test/home for u in `range `; do zfs create test/home/$u; done zpool export test zpool import -R /test test The zpool export command required about 30 minutes to finish. And the import command, after it did some silent work for 45 minutes, just reported a lot of error messages: ... cannot share 'test/home/4643': error reading /etc/dfs/sharetab cannot share 'test/home/8181': error reading /etc/dfs/sharetab cannot share 'test/home/1219': error reading /etc/dfs/sharetab cannot share 'test/home/3900': error reading /etc/dfs/sharetab cannot share 'test/home/7768': error reading /etc/dfs/sharetab cannot share 'test/home/1314': error reading /etc/dfs/sharetab cannot share 'test/home/3420': error reading /etc/dfs/sharetab cannot share 'test/home/7786': error reading /etc/dfs/sharetab cannot share 'test/home/9707': error reading /etc/dfs/sharetab ... Regards, Hans 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] x86 CPU Choice for ZFS
On Thu, 2006-07-06 at 01:57 -0700, Siegfried Nikolaivich wrote: > What kind of x86 CPU does ZFS prefer? In particular, what kind of CPU > is optimal when using RAID-Z with a large number of disks (8)? An additional point here: to an extent this depends on what you're going to be using the system for. I've got an old 733Mhz PentiumIII machine running the latest Nevada build, which happily runs ZFS -- it gets used as a simple backup via rsync server once a month or so, and happily manages ~180gb of data. cheers, tim -- Tim Foster, Sun Microsystems Inc, Operating Platforms Group Engineering Operationshttp://blogs.sun.com/timf ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] x86 CPU Choice for ZFS
Darren J Moffat writes: > Steven Sim wrote: > > Casper; > > > > Does this mean it would be a good practice to say increase the amount of > > memory and/or swap space we usually recommend if the customer intends to > > use ZFS very heavily? > > ZFS doesn't necessarily use more memory (physical or virtual) than UFS > it needs more VM *address space* (not the same as more VM) hence the 64 > bit processor. > > -- > Darren J Moffat > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss I concur and add 2 things: there is somewhat of a bug today in which ZFS allows application to dirtytoo much memory before being throttled. I mention this because, it's the issue that has created the notion the ZFS needs more ram; it does not. With better application throttling in place, this urban legend will debunk itself. Next, I'm not VM expert, but since ZFS does reference cached data in the kernel, I do think that it's a best practice to configure some extra swap to account for these larger kernels. -r ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: [raidz] file not removed: No space left on device
Unfortunately, truncating files doesn't work either. > > Eric Schrock wrote: > > > You don't need to grow the pool. You should always be able truncate the > > > file without consuming more space, provided you don't have snapshots. >[..] In the meantime, you can > truncate large files to free up space instead - because these don't > involve rewriting the parent directory pointers, this should always work. As quoted in the original posting, truncating did not work. It does "work" for files of size 0 though ;) (i.e. returns 0, while a failed truncate returns 1) 0 3 [EMAIL PROTECTED] pts/9 ~ 211# find . -type f -size 0 ./tex/latexmk/latexmk.txt ^C 1 3 [EMAIL PROTECTED] pts/9 ~ 212# :> ./tex/latexmk/latexmk.txt 0 3 [EMAIL PROTECTED] pts/9 ~ 213# find . -type f -size 1 [..] ./tex/labels/test/test2.tex ^C 1 3 [EMAIL PROTECTED] pts/9 ~ 214# ls -l ./tex/labels/test/test2.tex -rw-r--r-- 1 th122420 121 Nov 7 2005 ./tex/labels/test/test2.tex 0 3 [EMAIL PROTECTED] pts/9 ~ 215# :> ./tex/labels/test/test2.tex ./tex/labels/test/test2.tex: No space left on device. 1 3 [EMAIL PROTECTED] pts/9 ~ 216# :> /export/install/SunDownload/sol-nv-b42a-x86-v2-iso.zip /export/install/SunDownload/sol-nv-b42a-x86-v2-iso.zip: No space left on device. Other, more verbose means (than the shell NOP) of truncating a file give the same result. Unlink doesn't work either - returning 255: 0 3 [EMAIL PROTECTED] pts/9 ~ 219# unlink /export/install/SunDownload/sol-nv-b42a-x86-v2-iso.zip unlink: No space left on device 255 3 [EMAIL PROTECTED] pts/9 ~ 220# Interesting situation. -- Tatjana 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] x86 CPU Choice for ZFS
On Thu, 6 Jul 2006, Siegfried Nikolaivich wrote: [ ... reformatted ...] > Hello, > > What kind of x86 CPU does ZFS prefer? In particular, what kind of CPU > is optimal when using RAID-Z with a large number of disks (8)? BTW: I've read the existing followups (all good stuff!). 64-bit AMD > Does L2 cache size play a big role, 256kb vs 512kb vs 1MB? Are there > any performance improvements when using a dual core or quad processor > machine? Solaris code, in general, is designed to take advantage of extra L2 processor cache. As an aside, if you're looking at a 939-pin AMD CPU, grab one with 1Mb of cache (per core) quickly. The rumor is that large cache parts will become unavailable in the near future as AMD can squeeze more small cache CPUs per wafer - and bring them to market to counter the upcoming price war with Intel. PS: A big cut in AMD prices is rumored to be less than one month away - but, by then, the 1Mb cache parts may (or may not ??) be history. > I am choosing a CPU in a system primarily for ZFS and am wondering > whether paying the extra price for a larger cache or going dual core > will provide any benefits. Or would it be better to put the money > towards a higher clocked CPU? Solaris "likes" a system with 2 or more processors (or cores). It makes for a very responsive system. Recommendation: X2 4400+ for 939-pin single socket system will provide good long-term value. PS: Many had really good luck over-clocking the Model 165 Opteron (939-pin) dual-core part - it is a very easy/conservative overclock. Unfortunately, it is no longer available from AMD. You might try to EBay one. PPS: You may have noticed that the newer AM2 parts are mostly 512kb cache. Rumor is that parts with 256kb cache (ouch!) will be more easily available soon. Email me offlist if you have any further questions. Regards, Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris.Org Community Advisory Board (CAB) Member - Apr 2005 OpenSolaris Governing Board (OGB) Member - Feb 2006 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Supporting ~10K users on ZFS
On 7/6/06, H.-J. Schnitzer <[EMAIL PROTECTED]> wrote: The zpool export command required about 30 minutes to finish. And the import command, after it did some silent work for 45 minutes, just reported a lot of error messages: ... cannot share 'test/home/4643': error reading /etc/dfs/sharetab It seems as though these would come about if a memory allocation fails or there is a corrupt line in /etc/dfs/sharetab. Does /var/adm/messages have any messages indicating you were "out of space" (memory) or that / was full? Mike -- 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] x86 CPU Choice for ZFS
Darren J Moffat wrote: Steven Sim wrote: Casper; Does this mean it would be a good practice to say increase the amount of memory and/or swap space we usually recommend if the customer intends to use ZFS very heavily? ZFS doesn't necessarily use more memory (physical or virtual) than UFS it needs more VM *address space* (not the same as more VM) hence the 64 bit processor. offtopic query : How can ZFS require more VM address space but not more VM ? thanks. Pramod ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: Supporting ~10K users on ZFS
We have done some work to make this bearable on boot by introction of the undocumented SHARE_NOINUSE_CHECK environment variable. This disables an expensive check which verifies that the filesystem is not already shared. Since we're doing the initial shares on the system, we can safely disable this check. You may want to try your experiment with this environment variable set, but keep in mind that manually experimentation with this flag set coudl result in a subdirectory of a filesystem being shared at the same time as its parent, for example. To do much more we need to fundamentally rearchitect the was /etc/dfs/dfstab and /etc/dfs/sharetab work. Thankfully, there is already a project to rewrite all of this under the guise of a new 'share manager' command. The assumption is that, in addition to simplifying the administration model, it will also provide much greater scalability, as well as a programmatic method for sharing filesystems from within zfs(1M). You may want to ping nfs-discuss for any current status. - Eric On Thu, Jul 06, 2006 at 02:38:03AM -0700, H.-J. Schnitzer wrote: > Hi, > > does anybody successfully try the option sharenfs=on for an zfs filesystem > with 1 users? On my system (sol10u2), that is not only awfully slow but > does also not work smoothly. I did run the following commands: > > zpool create -R /test test c2t600C0FF00988193CD00CE701d0s0 > zfs create test/home > zfs set sharenfs=on test/home > for u in `range `; do zfs create test/home/$u; done > zpool export test > zpool import -R /test test > > The zpool export command required about 30 minutes to finish. > And the import command, after it did some silent work for 45 minutes, > just reported a lot of error messages: > > ... > cannot share 'test/home/4643': error reading /etc/dfs/sharetab > cannot share 'test/home/8181': error reading /etc/dfs/sharetab > cannot share 'test/home/1219': error reading /etc/dfs/sharetab > cannot share 'test/home/3900': error reading /etc/dfs/sharetab > cannot share 'test/home/7768': error reading /etc/dfs/sharetab > cannot share 'test/home/1314': error reading /etc/dfs/sharetab > cannot share 'test/home/3420': error reading /etc/dfs/sharetab > cannot share 'test/home/7786': error reading /etc/dfs/sharetab > cannot share 'test/home/9707': error reading /etc/dfs/sharetab > > ... > > Regards, > Hans > > > This message posted from opensolaris.org > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] x86 CPU Choice for ZFS
Hi;
I've just went through the following URL
http://blogs.sun.com/roller/page/roch?entry=the_dynamics_of_zfs
For those interested, I got to the above URL from
http://www.solarisinternals.com/wiki/index.php/Solaris_Internals_and_Performance_FAQ
Under the section ("DOES ZFS REALLY USE MORE RAM ?"), he clearly
elaborated ZFS's memory requirements.
For the offtopic query "How can ZFS require more VM address space but
not more VM ?", my simple explanation (which may be wrong) would be
That Solaris VM immediately "reserves" swap space upon memory request.
This takes place even though no actual physical page (and also VM page?)
is yet assigned to the malloc call. It was made very clear in the first
Edition of Solaris Internals that Solaris avoids the "lazy" method of
memory assignment used by AIX and Linux (which may result in things like
OOM described clearly in http://lwn.net/Articles/104179/
Am I right? Or completely off course?
Warmest Regards
Steven Sim
Pramod Batni wrote:
Darren J Moffat wrote:
Steven Sim wrote:
Casper;
Does this mean it would be a good practice to say increase the
amount of memory and/or swap space we usually recommend if the
customer intends to use ZFS very heavily?
ZFS doesn't necessarily use more memory (physical or virtual) than
UFS it needs more VM *address space* (not the same as more VM) hence
the 64 bit processor.
offtopic query :
How can ZFS require more VM address space but not more VM ?
thanks.
Pramod
Fujitsu Asia Pte. Ltd.
_
This e-mail is confidential and may also be privileged. If you are not the intended recipient, please notify us immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person.
Opinions, conclusions and other information in this message that do not relate
to the official business of my firm shall be understood as neither given nor
endorsed by it.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Re: x86 CPU Choice for ZFS
> But for ZFS, it has been said often that it currently performs > much better with a 64bit address space, such as that with > Opterons and other AMD64 CPUs. I think this would play a > bigger part in a ZFS server performing well than just MHZ > and cache size. I will no doubt be selecting a 64-bit capable CPU. My main concern is whether getting a dual core vs single core processor will give ZFS any noticable performance gain. Is ZFS multi-threaded in any way? I will also be heavily using NFS and possibly Samba, but a single core processor with a much higher clock speed is much cheaper than the dual core offerings from AMD. Also, there is a premium price for extra L2 cache. Would the ZFS checksum'ing and parity calculations benefit at all from a larger L2 cache, say 1MB? Or would the instructions fit fine inside 512kB? I know it depends on the application, but some general info on this subject will help my selection. 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] x86 CPU Choice for ZFS
>Darren J Moffat wrote: > >> Steven Sim wrote: >> >>> Casper; >>> >>> Does this mean it would be a good practice to say increase the amount >>> of memory and/or swap space we usually recommend if the customer >>> intends to use ZFS very heavily? >> >> >> ZFS doesn't necessarily use more memory (physical or virtual) than UFS >> it needs more VM *address space* (not the same as more VM) hence the >> 64 bit processor. >> >offtopic query : >How can ZFS require more VM address space but not more VM ? You mean, not more physical memory? Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] x86 CPU Choice for ZFS
On Thu, Jul 06, 2006 at 09:53:32PM +0530, Pramod Batni wrote: > >offtopic query : >How can ZFS require more VM address space but not more VM ? > The real problem is VA fragmentation, not consumption. Over time, ZFS's heavy use of the VM system causes the address space to become fragmented. Eventually, we will need to grab a 128k block of contiguous VA, but can't find a contiguous region, despite having plenty of memory (physical or virtual). This is only a problem on 32-bit kernels, because on a 64-bit kernel VA is effectively limitless. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: x86 CPU Choice for ZFS
with ZFS the primary driver isn't cpu, its "how many drives can one attach" :-) I use a 8 sata and 2 pata port http://supermicro.com/Aplus/motherboard/Opteron/nForce/H8DCE.cfm But there was a v20z I could steal registered ram and cpus from. H8DCE can't use the SATA HBA Framework which only supports Marvell 88SX and SI3124 controllers, so perhaps a 10 sata and 2 pata (14 drives!) http://www.amdboard.com/abit_sv-1a.html would be a better choice. Rob ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Re: x86 CPU Choice for ZFS
Siegfried Nikolaivich wrote: But for ZFS, it has been said often that it currently performs much better with a 64bit address space, such as that with Opterons and other AMD64 CPUs. I think this would play a bigger part in a ZFS server performing well than just MHZ and cache size. I will no doubt be selecting a 64-bit capable CPU. My main concern is whether getting a dual core vs single core processor will give ZFS any noticable performance gain. Is ZFS multi-threaded in any way? I will also be heavily using NFS and possibly Samba, but a single core processor with a much higher clock speed is much cheaper than the dual core offerings from AMD. You're still constrained by memory speed. Also, there is a premium price for extra L2 cache. Would the ZFS checksum'ing and parity calculations benefit at all from a larger L2 cache, say 1MB? Or would the instructions fit fine inside 512kB? I know it depends on the application, but some general info on this subject will help my selection. Cache works great for those things which are reused. There is relatively little data reuse in a file system. For ZFS, when you are checksumming or compressing data, there is almost zero reuse. I'd put my money in more cores and RAM rather than higher clock. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] COW question
question is ZFS uses COW(copy on write), does this mean it will double usage of capacity or waste the capacity? What COW really do? No mirror also has COW? Please help me, thanks. Robert ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] COW question
Robert Chen wrote: > question is ZFS uses COW(copy on write), does this mean it will > double usage of capacity or waste the capacity? > > What COW really do? No mirror also has COW? > > Please help me, thanks. > > Robert > > ___ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > It doesn't. Page 11 of the following slides illustrates how COW works in ZFS: http://www.opensolaris.org/os/community/zfs/docs/zfs_last.pdf "Blocks containing active data are never overwritten in place; instead, a new block is allocated, modified data is written to it, and then any metadata blocks referencing it are similarly read, reallocated, and written. To reduce the overhead of this process, multiple updates are grouped into transaction groups, and an intent log is used when synchronous write semantics are required."(from http://en.wikipedia.org/wiki/ZFS) IN snapshot scenario, COW consumes much less disk space and is much faster. Raymond ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
