Skip to Content
Last modified by Drunk Monkey on 2024-09-01 11:37
From version 1.6
edited by Drunk Monkey
on 2024-09-01 11:34
Change comment: There is no comment for this version
To version 1.7
edited by Drunk Monkey
on 2024-09-01 11:35
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -8,15 +8,16 @@
8 8  
9 9  The primary, and only function of the ZIL is to replay lost transactions in the event of a failure. When a power outage, crash, or other catastrophic failure occurs, pending transactions in RAM may have not been committed to slow platter disk. So, when the system recovers, the ZFS will notice the missing transactions. At this point, the ZIL is read to replay those transactions, and commit the data to stable storage. While the system is up and running, the ZIL is never read. It is only written to. You can verify this by doing the following (assuming you have SLOG in your system). Pull up two terminals. In one terminal, run an IOZone benchmark. Do something like the following:
10 10  
11 -{{{$ iozone -ao}}}
11 +{{code language="bash session"}}$ iozone -ao{{/code}}
12 12  
13 13  This will run a whole series of tests to see how your disks perform. While this benchmark is running, in the other terminal, as root, run the following command:
14 14  
15 -{{{# zpool iostat -v 1}}}
15 +{{code language="bash session"}}# zpool iostat -v 1{{/code}}
16 16  
17 17  This will clearly show you that when the ZIL resides on a SLOG, the SLOG devices are only written to. You never see any numbers in the read columns. This is becaus the ZIL is never read, unless the need to replay transactions from a crash are necessary. Here is one of those seconds illustrating the write:
18 18  
19 -{{{ capacity operations bandwidth
19 +{{code language="bash session"}}
20 + capacity operations bandwidth
20 20  pool alloc free read write read write
21 21  ------------------------------------------------------- ----- ----- ----- ----- ----- -----
22 22  pool 87.7G 126G 0 155 0 601K
... ... @@ -35,7 +35,7 @@
35 35   scsi-SATA_OCZ-REVODRIVE_XOCZ-THM0SU3H89T5XGR1-part5 26.5G 56.8G 0 0 0 0
36 36   scsi-SATA_OCZ-REVODRIVE_XOCZ-V402GS0LRN721LK5-part5 26.7G 56.7G 0 0 0 0
37 37   scsi-SATA_OCZ-REVODRIVE_XOCZ-WI4ZOY2555CH3239-part5 26.7G 56.7G 0 0 0 0
38 -------------------------------------------------------- ----- ----- ----- ----- ----- -----}}}
39 +------------------------------------------------------- ----- ----- ----- ----- ----- -----{{/code}}
39 39  
40 40  __//The ZIL should always be on non-volatile stable storage!//__ You want your data to remain consistent across power outages. Putting your ZIL on a SLOG that is built from TMPFS, RAMFS, or RAM drives that are not battery backed means you will lose any pending transactions. This doesn't mean you'll have corrupted data. It only means you'll have old data. With the ZIL on volatile storage, you'll never be able to get the new data that was pending a write to stable storage. Depending on how busy your servers are, this could be a Big Deal. SSDs, such as from Intel or OCZ, are good cheap ways to have a fast, low latentcy SLOG that is reliable when power is cut.
41 41