People asking for help and then rejecting advice

[Constantin]

Thank you! Bridge mode may be computationally too tough for the 1.7GHz processor in my system, I noted some pretty hilarious spikes as I started a rsync backup. 99% single core use may be related to SMB, but I don't recall same when I was using a hardware-offloaded, single NIC.

 

[Patrick M. Hausen]

This is going to improve greatly with TN 13. Currently all bridge code runs on only a single core.

 

[Bikerchris]

It appears to me that recently there is a growing number of people who first ask for help and then dispute the points they don't like to hear.

Hello Chris, apologies for bringing the original subject back

I merely wanted to say that I've been incredibly grateful for the help I've received on this forum, and although I've been absent for some time, it's only because I had plenty of knowledge voids filled by the excellent and experienced members.

It may help that my background isn't tech' based, well not at infrastructure levels at least. I'm sort of a construction Architect, so buildings are what I primarily know.

Just while writing, I'm getting very close to my ambition now - Primary server, snapshot server and off-site server (these are mostly self-built and often consist re-used workstation hardware). All running TrueNAS Core, more reliably and redundantly than any system I know.

So thank you again all

 

[fa2k]

I saw this topic by chance and it kind of hit me. I'm a bit like the people in the original topic, and I especially identify with the second post by sretalla. I love computers, and especially open source software, because anything is possible. I get a bit annoyed when people say something is not possible, when it's actually just a really bad idea.

It's pretty hard to physically destroy hardware, so in a home/lab system, the worst that can happen is that I have to spend a weekend rebuilding the whole thing from backups. I think TrueNAS rightfully attracts people interested in the tech, who like tinkering with it. (That's a good thing IMO, as long as they don't expect it to perform like an enterprise system.)

I have a lot of respect for the regulars on the forum, and I think that even if people seem to reject the advice, many will remember it. They may use a RAID controller at home and accept the risk, but will think twice before putting in production at work.

It would be nice if there was a "Stupid corner" of the forum where people discuss crazy things that aren't really supported, like oversized L2ARC, how to recover from partially destroyed pools, RAID controllers, etc. Then they know this is stupid, and you wouldn't have to tell them about best practices again and again. Like today, I wanted to also use my NAS as a video player, so I wanted to install Xorg -either in a jail (didn't work) or on the base system (still undecided). I knew better than to ask in the normal forums because I knew I'd be rightfully yelled at.

 

[danb35]

I get a bit annoyed when people say something is not possible,

But then you get things like a thread someone necro'd this morning, where the OP (over a year ago) was asking whether (and how) to go about removing panes from the "dashboard" page in the web UI. Someone else quickly and correctly responded that it's effectively not possible to do.

This morning, someone decides to necro the thread, saying that in a different, pre-release version of TrueNAS, of course it was possible--all you have to do is bang on the code for four days to get it to display the way you want (which then devolved into a bizarre discussion of F/OSS licenses). Was that useful to OP? Unlikely; presumably in the year since he posted he's got things working, or given up. Is it useful to anyone else? Doubtful; anyone with the ability to do it probably already knows that. So really, of what benefit is posting, "sure, it's possible; just re-code it until it works the way you want"?

 

[HoneyBadger]

It would be nice if there was a "Stupid corner" of the forum where people discuss crazy things that aren't really supported, like oversized L2ARC, how to recover from partially destroyed pools, RAID controllers, etc. Then they know this is stupid, and you wouldn't have to tell them about best practices again and again. Like today, I wanted to also use my NAS as a video player, so I wanted to install Xorg -either in a jail (didn't work) or on the base system (still undecided). I knew better than to ask in the normal forums because I knew I'd be rightfully yelled at.

If someone opens their post with "I'm aware this is a potentially silly or dangerous idea and I've accepted the risk" then I'm usually quite happy to give them directions on how to accomplish what they're asking, behind a "Here Be Dragons" spoiler warning so that others looking in the future don't just blindly apply the same guidance.

Some of the things fall into the category of "old knowledge that needs to be updated" eg: the L2ARC sizing guidance that still assumes the pre-OpenZFS merge header sizes, write throttle behavior, etc - and the outdated rules of thumb continue to get parroted on blogs, other forums, and social medias.

 

[danb35]

behind a "Here Be Dragons" spoiler warning

Oh, like this:

Creating a degraded pool

WARNING: HERE BE DRAGONS. IF YOU DON'T KNOW EXACTLY WHAT YOU'RE DOING, DO NOT FOLLOW THESE INSTRUCTIONS. IN FACT, IF YOU NEED THESE INSTRUCTIONS, YOU PROBABLY SHOULDN'T FOLLOW THEM. There are a few cases where it may make sense to create a...

www.truenas.com

 

[Merantza]

I see TUX in the SCALE announcement! Any chance for a Raspberry Pi implementation?

 

[Patrick M. Hausen]

I see TUX in the SCALE announcement! Any chance for a Raspberry Pi implementation?

Sorry, you are definitely in the wrong thread. You might want to start a new one in the TrueNAS SCALE section of the forum.

 

[artlessknave]

I see TUX in the SCALE announcement! Any chance for a Raspberry Pi implementation?

no. truenas is developed for enterprise use. the company is just reasonable enough to let us all use it, contribute to it, and benefits greatly by us all helping debug it and provide suggestions.
there is no enterprise customer who is going to expect high reliably storage on the cheapest hardware available, because rpi's are NOT high reliability.

 

[fa2k]

If someone opens their post with "I'm aware this is a potentially silly or dangerous idea and I've accepted the risk" then I'm usually quite happy to give them directions on how to accomplish what they're asking, behind a "Here Be Dragons" spoiler warning so that others looking in the future don't just blindly apply the same guidance.

I agree that's the best way..

But then you get things like a thread someone necro'd this morning, where the OP (over a year ago) was asking whether (and how) to go about removing panes from the "dashboard" page in the web UI. Someone else quickly and correctly responded that it's effectively not possible to do.

This morning, someone decides to necro the thread, saying that in a different, pre-release version of TrueNAS, of course it was possible--all you have to do is bang on the code for four days

Nice example, I agree that unmoderated hacky solutions can cause a lot of trouble for people with less experience following the instructions. It's likely to break things, if not immediately then on the next upgrade.

 

[danb35]

I agree that unmoderated hacky solutions can cause a lot of trouble for people with less experience following the instructions.

In that particular case there wasn't much of a risk of that; the new poster didn't give any kind of instructions. But OTOH, that made the post even less useful--not only does it not give a supported way to do what the OP had asked (which doesn't exist in CORE), it doesn't even give much guidance on an unsupported way to do it.

 

[HoneyBadger]

I agree that's the best way..

... unmoderated hacky solutions can cause a lot of trouble for people with less experience following the instructions

That's one of the drawbacks to the collaboration that a forum can enable. Someone comes in, and states "I'm setting this up in a home-lab for learning, I have all the time in the world, I'm doing routine and regular backups, and I won't be storing anything there I can't afford to lose. I want to do SILLY_THING()."

Then sure, do SILLY_THING() and enjoy the improved performance/learning experience that you get from it.

But then someone comes in looking to solve a similar issue under a different set of circumstances with a wildly different risk profile (business data, high uptime requirements, and data that can't be reproduced easily or at all) and blindly follows the instructions looking for "better performance" or "more space." SILLY_THING() faults and calls EAT_DATA() instead. Now we've got a business that's experiencing downtime, potentially of the permanent nature.

This is why often the first question I ask of anyone coming here with ambitions of storing someone's data (personal or business) is "are you willing to be the head on the chopping block if it goes awry?"

And if not, call someone who is.

 

[Arwen]

Reminds me of the test someone did of a SLOG built on an OS RAM disk. (Not dedicated, battery backed up device...) They were very impressed with the performance. But, of course, it was not persistent across reboots .

(To be clear, it was a TEST, and the implementor KNEW that it was not persistent on shutdown. Just comparing several SLOG variants.)