@cyberjock - as long as the disclaimer is here that he should expect
absolutely horrible performance then I don't see a problem with it. It's worthwhile doing it once on a non-production box just to see how abysmal it is, so that you've got some experience, and then he'll be the first in line to tell the next person thinking of doing it "Just don't."
But he's expecting absolutely horrible performance. He's also expecting to learn something because he wants to see how the L2ARC works. The problem with the whole theory: the L2ARC is NOT going to work like its supposed to because the ARC is going to be horribly starved.
The L2ARC grabs the pieces and parts of the ARC that are about to be evacuated, have been used enough times to make the L2ARC think that it is important. But what happens when every piece of data comes in, is used at most one time (and maybe not used at all), then targeted for evacuation by the ARC and removed because it was used only once. Yes, you can force the L2ARC to be very very greedy with tunables. You can make it grab almost every byte and force it to the L2ARC. You can constipate the hell out of the L2ARC device until the system is literally unusable because write and read speeds to/from the zpool are less than 10KB/sec, even for metadata reads (yes, I saw this once first-hand).
This has never been about performance. If performance was crap, but the pieces and parts of ZFS that manage the L2ARC and make the L2ARC actually doing what its supposed to do, I'd totally recommend people do it for the learning experience. You'd see me putting together an awesome guide on how you can learn about the L2ARC with small amounts of RAM. But there's a reason I don't. Because if data is being evacuated from the ARC due to high turnover due to the overhead of the L2ARC and everything else, the
L2ARC will not perform its function, as designed, so you will NOT see the L2ARC function as it is supposed to. So now you're going to only see one thing; how jacked up someone can make a system be and still not crash. That's it. Sorry, but there is no value to see how jacked up things can be until you've actually seen how it works properly. Without a fundamental, strong basis, with emphasis on seeing how it works properly in a well-configured system you are doing nothing to help yourself.
In fact, I'd argue you are setting yourself back because you are only seeing a system that is broken in various ways, and you are certainly not capable of identifying all of those ways.
It's like me buying a Smart Car, trying to tow it with 5000 lbs hitched to the back, and when I blow out the engine and transmission, I walk away from the poor Smart Car and try to tell people I learned something about the Smart Car and how it functions in a normal environment. No, you didn't. You learned it can't do what you want it to do "just because you wanted it to". You have no clue how good or bad it is on the sidestreets, the highway, taking it for a pleasure drive around town, etc. The Smart Car might be the smoothest ride you've ever been in. You might love how it handles, the power it has for its size, and how great it is when you want to go for a joy-ride at Midnight. But you won't be able to talk about those things because you blew up the poor car in the parking lot. You'll just tell everyone the Smart Car can't tow 5000 lbs. Well, no duh!
So yeah, only negative learning experience can be gained.
Let me ask you this question, since it's the same principle. Someone at your job gets handed a broken FreeNAS server. You've never heard of FreeNAS before, you have no experience outside of Windows desktop support. Which is a better situation to learn FreeNAS:
- You are handed a server that is broken (you don't even know what OS it uses), you find out from a few people in the forum that they may be running hardware RAID with ZFS, is short on RAM, has some weird boot error you can't begin to understand, and you aren't completely sure if that USB stick on the back is supposed to be there or not? There is no time-pressure because the boss isn't sure the server is even a server that has ever functioned.
- The guy that is told to learn FreeNAS and ZFS and gets to build a system with proper server-grade hardware, do ZFS without hardware RAID and has proper amounts of RAM so that ZFS can operate properly with ample ARC size.
I'm betting #2 will learn much faster than #1. And I'm betting its because he gets to see things work
properly and not because he got a crapload of warnings and he's got no choice but to ignore them because he's not even sure if turning a knob or pushing a button in the WebGUI might not give an outcome he can undo later.
I'm not pissed off or anything. I'm not on a rant. I'm pretty calm. I'm just trying to explain that seeing how an L2ARC won't work is no way to determine how an L2ARC "should" work. There is much more info to be learned seeing one operating properly, then seeing how a few tunables can totally break the L2ARC (maybe even the entire zpool) because of a single misconfigured tunable (again, i've seen this firsthand).
Doctor's don't learn about the human body by seeing a human body after it's been through a blender. They see the human body when it is working properly, then are trained on what can go wrong, how it goes wrong, the symptoms and the cures.
