Proper sizing of SLOG and transaction group

[depasseg]

I just removed my SLOG (200GB Intel S3700) from my pool reconfigured it as a 16GB device (using camcontrol HPA) and added it back to the pool using the GUI. I'll see if it makes a difference.

Code:

camcontrol security ada0 -e
camcontrol hpa     #to view current HPA settings
camcontrol hpa ada0 -s  31250000    # x 512B sectors =  16G

Interesting post of SSD performance and Over-Provisioning:
http://www.anandtech.com/show/6489/playing-with-op

 

[depasseg]

And from what I can figure out, there really isn't a difference between using the 2 methods. This isn't a SLOG issue, it's an SSD issue. In fact, the 3rd method (for desktop users) is just leave ~25% free space on the drive so the SSD controller has room to do it's cleanup and optimization. In the case of a SLOG where there is a heavy write stream, by limiting either the partition size or the HPA, the controller is guaranteed to have the extra space available.

 

[webpilot]

#depasseg, Looking at your footer system description, was the 16GB SLOG discussed above two separate intel devices reconfigured in a mirrored SLOG?

 

[depasseg]

No. It's an under provisioned 200GB single SSD.

 

[jgreco]

just leave ~25% free space on the drive so the SSD controller has room to do it's cleanup and optimization. In the case of a SLOG where there is a heavy write stream, by limiting either the partition size or the HPA, the controller is guaranteed to have the extra space available.

I've been promoting this for years, but iX isn't really interested in making a fix part of FreeNAS.

https://bugs.freenas.org/issues/2365

No one's demonstrated a credible case where using an appropriately sized SLOG device actually hurts, and under severe write pressure, having that guaranteed extra space available seems like it would range anywhere from irrelevant to a big win, depending on the specifics.

 

[webpilot]

Not to divert this topic, but is it best to implement SLOG and then test post and then test ARC to move forward to implement with L2ARC or vise versa?

 

[depasseg]

Not to divert this topic, but is it best to implement SLOG and then test post and then test ARC to move forward to implement with L2ARC or vise versa?

I don't think it matters. I did mine at the same time and without reboot (is that what "test post" meant?).

 

[jgreco]

If you're benchmarking, then, yes, you might want to test separately.

 

[webpilot]

I don't think it matters. I did mine at the same time and without reboot (is that what "test post" meant?).

Thanks for the clarification, I am moving forward to set up a 200GB intel S3710 as an SLOG under provisioned as 16gb (Still researching). Did you also under provision the L2ARC SSD? Adding the L2ARC at the same time could be interesting and pricey for me since some post indicators point to going five times the ARC size.

If you're benchmarking, then, yes, you might want to test separately.

I am trying to determine the best benchmarking scenario as I have a mixed file size usage over CIFS that pulls large 300+ gb compressed files sometimes and then lots of little files from all over the data set. The ARC has been sitting around 99G on the large file transfers. The size of working files will drop considerably in a couple of months so I will factor that in. I will get the SLOG addition complete and determine what will be the best tests to determine the pre L2ARC capacity to balance out future use as I will be possibly adding the next size up S3710 for that.

 

[depasseg]

Thanks for the clarification, I am moving forward to set up a 200GB intel S3710 as an SLOG under provisioned as 16gb (Still researching). Did you also under provision the L2ARC SSD? Adding the L2ARC at the same time could be interesting and pricey for me since some post indicators point to going five times the ARC size.

No, I kept my L2ARC at 200GB. I only underprovisioned the SLOG. You can use a smaller L2ARC, you just need to make sure that you have at least 1/5*L2ARC in RAM. The "five times the ARC" is a max recommendation.

 

[webpilot]

To clarify parts for under provisioning. The newly added 3710 SSD is not in a pool and just listed in the view disks list as da12.

Use the shell / Putty to perform the under provisioning steps as listed before via camcontrol on da12

1. camcontrol security da12 -e
2. camcontrol hpa da12 #to view current HPA settings
3. camcontrol hpa da12 -s 31250000 # x 512B sectors = 16G

Then use volume manager to extend the volume called "Tank". Add the available da12 disk as 200GB under provisioned as above, change the volume layout to Log (ZIL), and extend the volume to add the ZIL.

Now that the zil/slog is added. are these follow-up steps to do before testing or leave defaults and go with autotune?
Disable 'writeback cache' on every unit created from a zvol
Set sync=always on the pool itself

Thanks in advance

 

[webpilot]

When provisioned via camcontrol, the SLOG should show up as 16GB correct? I did the same process above on a PE R510 with the same hardware Build 1 setup and it displays 16GB. The R515 and the 3710 above showed up as 200GB not 16GB. I will reboot and re-issue the camcontrol commands.

 

[depasseg]

That's right - the disk will look like it's 16GB. Assuming you did the math correctly.

 

[webpilot]

I believe that one additional reboot was needed. Here is the summary of all the steps taken.

In regard to the setting up the R515 & R510 volume with a SLOG;

• Installed 9.3.1 stable
• Updated to 9.3.1 version that was same as backed up configuration file. System rebooted as part of upgrade.
• Uploaded config, system rebooted as part of upload.
• updated SLOG SSD device provisioning via camcontrol - SSD in disk list still showed 200GB. camcontrol showed that revised sector count was in place.
• Rebooted server,
• now disk list shows SSD at 16GB as a different da## listing
• Expanded main volume / pool with ZIL LOG using 16GB SSD.
• Did not need to reboot to see in reporting or other disk based lists.

I hope that this helps some others.

 

[webpilot]

@depasseg, thanks for the reply. I think I have the two boxes strait now in terms of SLOG. I am now searching for some tests to determine post results.

 

[webpilot]

Does anyone know if the 3710 SSD will reset back to 200GB from under provisioned 16GB if the system is rebooted? I had to re-run the commands and re-attach via volume manager.

 

[depasseg]

The camcontrol settings survive reboots and power loss.

 

[webpilot]

I was curious as I moved my freenas main setup from an AMD R515 server to a Xeon R510. The 12 pool disks, HBA, NIC, and SLOG SSD components were powered down and moved from box to another. The SATA backplanes were different in each box. After reboot, the SSD came up in the disk list as 200GB. I wanted to point out that the freenas 9.3.1 version did not require an update in this case.

My replication freenas box R510 #2 which had no hardware moves or changes was powered down to physically move it and clean it. Both power supplies were disconnected in this case. When I rebooted the device, the SLOG disk reverted to 200GB from 16G. As on the server above, I had to remove the SLOG device from the pool, re-run camcontrol commands and then re-extend the main pool. It then showed as 16GB after a reboot. I will keep an eye on it. This box had an update performed on it before I checked the SLOG, but I did not think that would effect the SLOG.

I will update the post if anything definitive is noticed. The specs on the units are in the footer.

 

[webpilot]

I can confirm that on both units running 9.3-STABLE-201512121950 the under provisioned intel 3710 SSD reverted back to the full capacity after a reboot.

Is it possible that the last upgrade did something to keeping camcontrol commands from being left in place? What is the next step? Contact intel or can anyone offer something else to try. I try not to reboot that often. See the output of camcontrol below:

[root@carrier ~]# camcontrol hpa da10
pass10: <INTEL SSDSC2BA200G4 G2010110> ATA-9 SATA 3.x device
pass10: 600.000MB/s transfers, Command Queueing Enabled

Feature Support Enabled Value
Host Protected Area (HPA) yes no 390721968/390721968
HPA - Security no

 

[jgreco]

It probably doesn't matter if the device reverts in size. As long as the partition that's been created by FreeNAS is the smaller size, this implies that most of the pages on the SSD will never be allocated to LBA's, meaning that the large bucket of free pages (which is mostly what we're trying to accomplish with underprovisioning) is achieved anyways.