Is there any way run start-up script before non-root pool is mounted ? For example I''m trying to use ramdisk as ZIL device (ramdiskadm ) So I need to create ramdisk before actual pool is mounted otherwise it complains that log device is missing :) For sure I can manually remove/and add it by script and put the script in regular rc2.d location...I''m just looking for more elegant way to it. Thanks a lot. -- This message posted from opensolaris.org
On Wed, 2010-08-18 at 00:16 -0700, Alxen4 wrote:> Is there any way run start-up script before non-root pool is mounted ? > > For example I''m trying to use ramdisk as ZIL device (ramdiskadm ) > So I need to create ramdisk before actual pool is mounted otherwise it complains that log device is missing :) > > For sure I can manually remove/and add it by script and put the script in regular rc2.d location...I''m just looking for more elegant way to it. > > > Thanks a lot.You *really* don''t want to use a ramdisk as your ZIL. You''d be better off just disabling the zil altogether. - Garrett
Alxen4 wrote:> Is there any way run start-up script before non-root pool is mounted ? > > For example I''m trying to use ramdisk as ZIL device (ramdiskadm ) > So I need to create ramdisk before actual pool is mounted otherwise it complains that log device is missing :) > > For sure I can manually remove/and add it by script and put the script in regular rc2.d location...I''m just looking for more elegant way to it. >Can you start by explaining what you''re trying to do, because this may be completely misguided? A ramdisk is volatile, so you''ll lose it when system goes down, causing failure to mount on reboot. Recreating a ramdisk on reboot won''t recreate the slog device you lost when the system went down. I expect the zpool would fail to mount. Furthermore, using a ramdisk as a ZIL is effectively just a very inefficient way to disable the ZIL. A better way to do this is to "zfs set sync=disabled ..." on relevant filesystems. I can''t recall which build introduced this, but prior to that, you can set zfs://zil_disable=1 in /etc/system but that applies to all pools/filesystems. -- Andrew Gabriel
Any argumentation why ? -- This message posted from opensolaris.org
On Wed, 2010-08-18 at 00:49 -0700, Alxen4 wrote:> Any argumentation why ?Because a RAMDISK defeats the purpose of a ZIL, which is to provide a fast *stable storage* for data being written. If you are using a RAMDISK, you are not getting any non-volatility guarantees that the ZIL is supposed to offer. You may as well run without one. (Which will go fast, but at the expense of data integrity.) - Garrett
Andrew Gabriel wrote:> Alxen4 wrote: >> Is there any way run start-up script before non-root pool is mounted ? >> >> For example I''m trying to use ramdisk as ZIL device (ramdiskadm ) >> So I need to create ramdisk before actual pool is mounted otherwise >> it complains that log device is missing :) >> >> For sure I can manually remove/and add it by script and put the >> script in regular rc2.d location...I''m just looking for more elegant >> way to it. > > Can you start by explaining what you''re trying to do, because this may > be completely misguided? > > A ramdisk is volatile, so you''ll lose it when system goes down, > causing failure to mount on reboot. Recreating a ramdisk on reboot > won''t recreate the slog device you lost when the system went down. I > expect the zpool would fail to mount. > > Furthermore, using a ramdisk as a ZIL is effectively just a very > inefficient way to disable the ZIL. > A better way to do this is to "zfs set sync=disabled ..." on relevant > filesystems. > I can''t recall which build introduced this, but prior to that, you can > set zfs://zil_disable=1 in /etc/system but that applies to all > pools/filesystems. >The double-slash was brought to you by a bug in thunderbird. The original read: set zfs:zil_disable=1 -- Andrew Gabriel
Thanks...Now I think I understand... Let me summarize it andd let me know if I''m wrong. Disabling ZIL converts all synchronous calls to asynchronous which makes ZSF to report data acknowledgment before it actually was written to stable storage which in turn improves performance but might cause data corruption in case of server crash. Is it correct ? In my case I''m having serious performance issues with NFS over ZFS. My NFS Client is ESXi so the major question is there risk of corruption for VMware images if I disable ZIL ? Thanks. -- This message posted from opensolaris.org
Alxen4 wrote:> Thanks...Now I think I understand... > > Let me summarize it andd let me know if I''m wrong. > > Disabling ZIL converts all synchronous calls to asynchronous which makes ZSF to report data acknowledgment before it actually was written to stable storage which in turn improves performance but might cause data corruption in case of server crash. > > Is it correct ? > > In my case I''m having serious performance issues with NFS over ZFS. >You need a non-volatile slog, such as an SSD.> My NFS Client is ESXi so the major question is there risk of corruption for VMware images if I disable ZIL ? >Yes. If your NFS server takes an unexpected outage and comes back up again, some writes will have been lost which ESXi thinks succeeded (typically 5 to 30 seconds worth of writes/updates immediately before the outage). So as an example, if you had an application writing a file sequentially, you will likely find an area of the file is corrupt because the data was lost. -- Andrew Gabriel
On Wed, 2010-08-18 at 01:20 -0700, Alxen4 wrote:> Thanks...Now I think I understand... > > Let me summarize it andd let me know if I''m wrong. > > Disabling ZIL converts all synchronous calls to asynchronous which makes ZSF to report data acknowledgment before it actually was written to stable storage which in turn improves performance but might cause data corruption in case of server crash. > > Is it correct ? > > In my case I''m having serious performance issues with NFS over ZFS. > My NFS Client is ESXi so the major question is there risk of corruption for VMware images if I disable ZIL ?Yes. If your server crashes, you can lose data. - Garrett> > > Thanks.
Thanks.Everything is clear now. -- This message posted from opensolaris.org
Il giorno 18/ago/2010, alle ore 10.20, Alxen4 ha scritto:> My NFS Client is ESXi so the major question is there risk of corruption for VMware images if I disable ZIL ?I do the same use of ZFS. I had a huge improvement in performance by using mirrors instead of raidz. How is your zpool configured? -- Simone Caldana Senior Consultant Critical Path via Cuniberti 58, 10100 Torino, Italia +39 011 4513811 (Direct) +39 011 4513825 (Fax) simone.caldana at criticalpath.net http://www.cp.net/ Critical Path A global leader in digital communications
On Wed, Aug 18, 2010 at 12:16:04AM -0700, Alxen4 wrote:> Is there any way run start-up script before non-root pool is mounted ? > > For example I''m trying to use ramdisk as ZIL device (ramdiskadm ) > So I need to create ramdisk before actual pool is mounted otherwise it complains that log device is missing :)Yes, it''s actually quite easy. You need to create an SMF manifest and method. The manifest should make the ZFS mount dependant on it with the `dependent'' and `/dependent'' tag pair. It also needs to be dependant on resources it needs, with the `dependency'' and `/dependency'' pairs. It should also specify a `single_instance/'' and `transient'' service. The method script can do whatever the mount requires, such as creating the ramdisk. -- -Gary Mills- -Unix Group- -Computer and Network Services-
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Alxen4 > > Disabling ZIL converts all synchronous calls to asynchronous which > makes ZSF to report data acknowledgment before it actually was written > to stable storage which in turn improves performance but might cause > data corruption in case of server crash. > > Is it correct ?It is partially correct. With the ZIL disabled, you could lose up to 30 sec of writes, but it won''t cause an inconsistent filesystem, or "corrupt" data. If you make a distinction between "corrupt" and "lost" data, then this is valuable for you to know: Disabling the ZIL can result in up to 30sec of lost data, but not corrupt data.
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Alxen4 > > For example I''m trying to use ramdisk as ZIL device (ramdiskadm )Other people have already corrected you about ramdisk for log. It''s already been said, use SSD, or disable ZIL completely. But this was not said: In many cases, you can gain a large performance increase by enabling the WriteBack buffer of your ZFS server raid controller card. You only want to do this if you have a BBU enabled on the card. The performance gain is *not* quite as good as using a nonvolatile log device, but certainly worth checking anyway. Because it''s low cost, and doesn''t consume slots... Also, if you get a log device, you want two of them, and mirror them.
andrew.gabriel at oracle.com
2010-Aug-18 16:32 UTC
[zfs-discuss] Solaris startup script location
What you say is true only on the system itself. On an NFS client system, 30 seconds of lost data in the middle of a file (as per my earlier example) is a corrupt file. -original message- Subject: Re: [zfs-discuss] Solaris startup script location From: Edward Ned Harvey <shill at nedharvey.com> Date: 18/08/2010 17:17> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Alxen4 > > Disabling ZIL converts all synchronous calls to asynchronous which > makes ZSF to report data acknowledgment before it actually was written > to stable storage which in turn improves performance but might cause > data corruption in case of server crash. > > Is it correct ?It is partially correct. With the ZIL disabled, you could lose up to 30 sec of writes, but it won''t cause an inconsistent filesystem, or "corrupt" data. If you make a distinction between "corrupt" and "lost" data, then this is valuable for you to know: Disabling the ZIL can result in up to 30sec of lost data, but not corrupt data. _______________________________________________ zfs-discuss mailing list zfs-discuss at opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss