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

Summary

Details

Page properties
Content
... ... @@ -8,11 +8,15 @@
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 -{{code language="bash session"}}$ iozone -ao{{/code}}
11 +{{code language="bash session"}}
12 +$ iozone -ao
13 +{{/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 -{{code language="bash session"}}# zpool iostat -v 1{{/code}}
17 +{{code language="bash session"}}
18 +# zpool iostat -v 1
19 +{{/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  
... ... @@ -36,7 +36,8 @@
36 36   scsi-SATA_OCZ-REVODRIVE_XOCZ-THM0SU3H89T5XGR1-part5 26.5G 56.8G 0 0 0 0
37 37   scsi-SATA_OCZ-REVODRIVE_XOCZ-V402GS0LRN721LK5-part5 26.7G 56.7G 0 0 0 0
38 38   scsi-SATA_OCZ-REVODRIVE_XOCZ-WI4ZOY2555CH3239-part5 26.7G 56.7G 0 0 0 0
39 -------------------------------------------------------- ----- ----- ----- ----- ----- -----{{/code}}
43 +------------------------------------------------------- ----- ----- ----- ----- ----- -----
44 +{{/code}}
40 40  
41 41  __//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.
42 42  
... ... @@ -52,8 +52,7 @@
52 52  
53 53  In the image below, I tried to capture a simplified view of the first process. The pink arrows, labeled as number one, show the application committing its data to both RAM and the ZIL. Technically, the application is running in RAM already, but I took it out to make the image a bit more clean. After the blocks have been committed to RAM, the platter ACKs the write to the ZIL, noted by the green arrow labeled as number two. Finally, ZFS flushes the data blocks out of RAM to disk as noted by the gray arrow labeled as number three.
54 54  
55 -
56 -[[image:https://web.archive.org/web/20210430213036im_/http://pthree.org/wp-content/uploads/2013/04/platter-sync-zil.png||alt="Show how a synchronous write works with ZFS and the ZIL on platter."]]
60 +[[image:platter-sync-zil.png||alt="Show how a synchronous write works with ZFS and the ZIL on platter."]]
57 57  //Image showing a synchronous write with ZFS without a SLOG//
58 58  
59 59  
... ... @@ -65,8 +65,7 @@
65 65  
66 66  As shown in the image, again the pink arrows labeled number one show the application committing its data to both the RAM and the ZIL on the SLOG. The SLOG ACKs the write, as identified by the green arrow labeled number two, then ZFS flushes the data out of RAM to platter as identified by the gray arrow labeled number three.
67 67  
68 -
69 -[[image:https://web.archive.org/web/20210430213036im_/http://pthree.org/wp-content/uploads/2013/04/slog-sync-zil.png||alt="Show how a synchronous write works with ZFS and the ZIL on a SLOG."]]
72 +[[image:slog-sync-zil.png||alt="Show how a synchronous write works with ZFS and the ZIL on a SLOG."]]
70 70  //Image showing a synchronous write with ZFS with a SLOG//
71 71  
72 72  
platter-sync-zil.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.pdwalker
Size
... ... @@ -1,0 +1,1 @@
1 +15.2 KB
Content
slog-sync-zil.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.pdwalker
Size
... ... @@ -1,0 +1,1 @@
1 +17.5 KB
Content