Repurposing SSDs for ZIL and L2ARC

Fuzzball

Fuzzball

I've got a couple of SSDs that I want to repurpose for ZIL and L2ARC. I want to ensure the previous usage doesn't negatively affect performance. I remember in the past that a secure erase was the only way to restore performance and I haven't found anything to the contrary yet. I investigated doing a secure erase, but my Google-Fu is failing to give me a solid answer beyond yanking the drive and running a Windows utility. In camcontrol() I see camcontrol sanitize and camcontrol security, but the man page didn't inspire confidence that was what I was looking for; I'm not interested in setting a password if it needs to be put in after each reboot. I've also read that newfs -E may get the job done, but my understanding is it just writes zeros and doesn't activate any kind of garbage collection or do a secure erase.

Would camcontrol security da0 -s Erase -e Erase do it and is there anything else I need to do to prep the drive?

The other thing I'm curious of is 4k alignment on the drives. In my googling I didn't find anything similar to the gnop trick. So would the below be all I needed to ensure 4k alignment?
gpart create -s gpt da0
gpart create -s gpt da1
gpart add -t freebsd-zfs -a 4k -l tanklog-0 -s 200G da0
gpart add -t freebsd-zfs -a 4k -l tankcache-0 -s 200G da1
zpool add tank log tanklog-0
zpool add tank cache cache-0

I appreciate it.
 
wblock@ said:
If TRIM was enabled in the previous usage, a secure erase should not be needed.
Click to expand...
It was enabled, but there was a lot of data before the partition was deleted. I don't think garbage collection had any time to run before hand. Long story on what happend. :OOO
 
The drives should have been updating the in-use block list in the background all the time. So at worst, some blocks are still thought to be in use when they are not. camcontrol(8) shows the secure erase command as above. The example is not very specific about the passwords, but it appears to have worked for others.
 
Note: 200 GB for a SLOG is extreme overkill! A SLOG only needs to be large enough to hold 1 transaction group of data, which is generally 10-30 seconds worth of sync writes, which shouldn't be more than a handful of GB (if even that much).

If you have 2 SSDs that are identical, then you could partition them up with 2 partitions (a 10-20 GB for the SLOG, and [the rest - 25%] for the L2ARC). Then you can add the two SLOG partitions as a mirrored log vdev, and the two L2ARC partitions as cache (not mirrored) vdev.

To improve performance of the SSDs over time, leave approx 25% of it as unpartitioned, free space. That way, the garbage collection routines will have a lot of "spare" sectors to use.

Also, if this is on newer FreeBSD versions, TRIM is run automatically when you add SSDs to a pool.
 
Thanks everyone for the info. I did use the camcontrol ()secure erase I referenced in the original post without an issue. Running camcontrol identify on the drive afterwards shows that security is not enabled, which I was concerned it would be.

I did consider @phoenix's recommendation, but I ended up finding a smaller drive that had faster writes to use for the log. I've left plenty of space unpartitioned for both drives. Now to see how everything performs.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top