|
Ideal in terms of metadata overhead vs. slack space over in the filesystem running in the ZVOL, for general purpose use. Like that diskless boot workstation that spawned this discussion. At least in my opinion. I forgot what the exact values where, but with 4K block sizes, there's 6% overhead in on-disk metadata, with 8K just 3% and with 16K obviously just 1.5%. Same goes for L2ARC block pointers, which are 170 bytes in OpenZFS (Oracle eventually changed things and their ZFS implementation needs only 90 bytes), for each data and metadata block that spilled into L2ARC. Not sure what's the point of this blocks vs. files thing. It's the same difference in most cases. Either way, ZFS has the zprefetch module, which reads ahead a drat lot if it thinks it's worthwhile (and yeah, it works on block level). It has linear and stride read detection, so if it thinks it spotted a pattern, it'll effectively preload the ARC (and old stuff will spill over into L2ARC).
|
#
?
Mar 28, 2017 22:30
|
|
|
|
| # ? May 24, 2024 23:58 |
|
|
Combat Pretzel posted:Ideal in terms of metadata overhead vs. slack space over in the filesystem running in the ZVOL, for general purpose use. Like that diskless boot workstation that spawned this discussion. At least in my opinion. What I, backed by what an openzfs developer wrote in that mailing list post, am saying is the NTFS writes and reads that you're getting from the iSCSI initiator running on the diskless workstation, which is accessing the iSCSI target in the FreeBSD kernel, are always gonna be either 512 bytes or 4k bytes depending on whichever the disk was formatted with. That's what I'm talking about matching volblocksize to, since that's the actual size of the write and read and it doesn't vary. Whatever overhead in ZFS, that's associated with the block level device that ZFS presents to the iSCSI kernel initiator, is up to ZFS to figure out on it's own, because it was made to do that. If you then enable MTU Jumbo Frames, the link will only send one packet for each I/O operation. Also, L2ARC isn't special. It's just a secondary ARC where everything that doesn't fit in memory gets loaded off to, but it needs to be mapped in memory, and that mapping takes up space, especially if the L2ARC is big enough - hence why you should maximize your systems memory before adding L2ARC since it's 1) considerably slower, and 2) requires mapping in memory, which takes away ARC space. And as I said before, it only matters if your cache hit ratio is so low that stuff you'd want in the ARC doesn't end up there. Additionally, you're talking about zfetch which tries to work on a file level (technically speaking it's any streaming data, but since you're operating with a block device from an OS that you can't rely on to not interrupt I/O streams, I'm not sure that's gonna do much for you), isn't very well documented/benchmarked and is disabled for quite a number of workloads. Brendan Gregg of dtrace fame has an excellent article on how the ARC works with MFU and MRU algoritms. BlankSystemDaemon fucked around with this message at 23:42 on Mar 28, 2017 |
|
#
?
Mar 28, 2017 23:12
|
|
|
Looking for some feedback/opinions: Thinking of getting a newer synology dsm box for ~$300-500. Im not a hardcore admin and don't really want to spend 3 weeks on the learning curve of rolling my own. I like the flexibility, ease of use of and all the services available on the dsm - plus I like the appliance form factor. Any reason I shouldn't go this route - better options beside roll my own? Thanks!
|
|
#
?
Mar 29, 2017 00:25
|
|
|
D. Ebdrup posted:We're talking about two different things here, I think. quote:What I, backed by what an openzfs developer wrote in that mailing list post, am saying is the NTFS writes and reads that you're getting from the iSCSI initiator running on the diskless workstation, which is accessing the iSCSI target in the FreeBSD kernel, are always gonna be either 512 bytes or 4k bytes depending on whichever the disk was formatted with. That's what I'm talking about matching volblocksize to, since that's the actual size of the write and read and it doesn't vary. (Of couse, if you have a very specific workload, like database which are fickle regarding cluster sizes, go plan around it with volblocksize.) quote:Whatever overhead in ZFS, that's associated with the block level device that ZFS presents to the iSCSI kernel initiator, is up to ZFS to figure out on it's own, because it was made to do that. Additional overhead, that I failed to mention before, is introduced via fragmentation. A COW filesystem goes to poo poo quickly, and larger clusters in the hosted filesystem, and subsequently the ZVOL, may likely end up in better performance, because typical workloads aren't purely random 4K IO, but reads of larger sequential sections of data (yeah, I know that there's opposite cases like compilation and such). In the worst case scenario, it'll have to seek to less locations on the disk to retrieve the data. Also, I think iSCSI can pack multiple IOs into a packet, if the MTU allows it. quote:Also, L2ARC isn't special. It's just a secondary ARC where everything that doesn't fit in memory gets loaded off to, but it needs to be mapped in memory, and that mapping takes up space, especially if the L2ARC is big enough - hence why you should maximize your systems memory before adding L2ARC since it's 1) considerably slower, and 2) requires mapping in memory, which takes away ARC space. And as I said before, it only matters if your cache hit ratio is so low that stuff you'd want in the ARC doesn't end up there. The point about the huge L2ARC was to reduce the instances of going to spindles to an absolute minimum. The SSD-like performance target goes to poo poo when the server needs to hit the disks. Of course, given "small" SSDs and a huge backing array, you can't avoid it, but I'd like to sure as hell have as much data as possible to be at least tepid warm. The L2ARC on an SSD is certainly way faster than the spindles, so it being slower than RAM means not much in the grand scheme. As far as memory goes, as I've said multiple times now, each block in the L2ARC needs 170 bytes in the ARC. I posted an example in the last post, 768GB of 16K blocks would "only" hog 8GB of RAM, which wouldn't be much in a NAS with 32GB. Even if you were to insist on 4K blocks, that'd still allow you to keep 192GB on fast storage. I'd say 192GB for 8GB is a good trade-off. (Of course, the actual planning has to go the opposite way, you'll esimate how large your L2ARC should to be based on how much RAM you're willing to sacrifice to it.) quote:Additionally, you're talking about zfetch which tries to work on a file level (technically speaking it's any streaming data, but since you're operating with a block device from an OS that you can't rely on to not interrupt I/O streams, I'm not sure that's gonna do much for you), isn't very well documented/benchmarked and is disabled for quite a number of workloads. Brendan Gregg of dtrace fame has an excellent article on how the ARC works with MFU and MRU algoritms. --edit: Back when I ran Windows in a KVM with GPU passthrough, I ran my VMs on iSCSI extents wrapped in a 192GB bcache. That certainly worked well to boot Windows and then play GTA and Just Cause 3 back and forth without really touching any of the disks over on the NAS via 1GbE (other than sending access time updates and actual writes I guess). Maybe that helps understanding the idea about the huge L2ARC. Combat Pretzel fucked around with this message at 02:40 on Mar 29, 2017 |
|
#
?
Mar 29, 2017 02:21
|
|
|
Combat Pretzel posted:Back when I ran Windows in a KVM with GPU passthrough, I ran my VMs on iSCSI extents wrapped in a 192GB bcache. I feel like I've heard this on an episode of CSI before.
|
|
#
?
Mar 29, 2017 19:09
|
|
|
ch1mp posted:Looking for some feedback/opinions: The big complaint I see about Synology units is that the processor isn't good enough for HD transcoding with Plex. If that isn't an issue for you, they are pretty nice units overall.
|
|
#
?
Mar 29, 2017 21:03
|
|
|
The CTO of iXsystems and project leader of FreeNAS is leaving the company in a week to move on to "the nanotech / biomedical field" https://forums.freenas.org/index.php?threads/moving-on-from-ixsystems-and-the-future-of-freenas-corral.52426/
|
|
#
?
Mar 29, 2017 21:13
|
|
|
I've used FreeNAS since version 8 and it seems to be really losing its way. I can't see that this is going to help. 
|
|
#
?
Mar 29, 2017 23:09
|
|
|
Touchfuzzy posted:I feel like I've heard this on an episode of CSI before. GPU passthrough = Giving your VM direct hardware access to the graphics card. iSCSI extent = What you basically call a partition on a NAS, that's accessible via iSCSI (I don't think that acronym needs explanation in this thread?) bcache = Some block device driver in Linux, which lets you use one block device, like an SSD, to run a cache for another block device. TTerrible posted:I've used FreeNAS since version 8 and it seems to be really losing its way. I can't see that this is going to help.
|
|
#
?
Mar 30, 2017 02:09
|
|
|
The realist me says he's just done with that particular sector of of business and was waiting for Corral to be out before he could leave but the cynic in me says they rushed it out so he could leave sooner. One of his decisions lead to the current state of the documentation for Corral it feels like.
|
|
#
?
Mar 30, 2017 03:53
|
|
|
Droo posted:The big complaint I see about Synology units is that the processor isn't good enough for HD transcoding with Plex. If that isn't an issue for you, they are pretty nice units overall. I think QNAP have provided support for the recent beta work with Plex hardware-based transcoding on-chip. No such luck with Synology yet, you're stuck with DS Video if you want that on suitable Synology models.
|
|
#
?
Mar 30, 2017 21:39
|
|
|
Decairn posted:I think QNAP have provided support for the recent beta work with Plex hardware-based transcoding on-chip. No such luck with Synology yet, you're stuck with DS Video if you want that on suitable Synology models. Hmm, does this concern apply to the latest synology units? Both QNAP and the newer synology run the same chip - N3150. Maybe thats not relevant, I'm not an expert. Also, Synology claims 4k transcoding - is that BS? Thanks!
|
|
#
?
Mar 30, 2017 21:47
|
|
|
Combat Pretzel posted:Those are some encouraging words... I liked 9 but the decisions in 10 are just baffling to me. Docker? Really? People have mentioned a few other strange regressions in behaviour.
|
|
#
?
Mar 31, 2017 00:55
|
|
|
ch1mp posted:Hmm, does this concern apply to the latest synology units? Both QNAP and the newer synology run the same chip - N3150. Maybe thats not relevant, I'm not an expert. Also, Synology claims 4k transcoding - is that BS? Thanks! It needs some software support from Synology to switch the chip-feature on, and that's not done yet AFAIK.
|
|
#
?
Mar 31, 2017 01:22
|
|
|
From what I read in small net builder the synology 4K decode is actually a gimmicky tag line instead of an actual useful feature. The synology unit needs to run on synology video to actually work
|
|
#
?
Mar 31, 2017 01:34
|
|
|
TTerrible posted:I liked 9 but the decisions in 10 are just baffling to me. Docker? Really? People have mentioned a few other strange regressions in behaviour. I have no outright complaints with Docker replacing jails, I've had far less issues permissions wise when setting them up. On a lark, I looked up their bug/feature request list for U1. It's uh, rather sizable.  https://bugs.freenas.org/versions/384 Edit: These people are insane though: https://bugs.freenas.org/issues/21972
|
|
#
?
Mar 31, 2017 01:43
|
|
|
TTerrible posted:I liked 9 but the decisions in 10 are just baffling to me. Docker? Really? People have mentioned a few other strange regressions in behaviour. For all the misgivings I have for Docker as a thing, it's extremely good as a replacement for the old plugins. There's a few minor UI quirks but other than that Corral has been great. It's not uncommon for a project lead to quit after a big release. The only concern I have is that thought they could release without actual documentation 
|
|
#
?
Mar 31, 2017 02:18
|
|
|
I need some help deciding what to buy, there's just too many options. I watch stuff using Kodi on a Fire TV, so I think I don't need a powerful CPU in my NAS, right? What it needs to be able to do is run Sonarr, Couchpotato and download and unpack stuff from Usenet. I guess I should use 3 disks in raid 5 for some redundancy? I probably don't need it running 24/7, can you set these thing up to turn themselves on at specific times, check for downloads and then turn themselves off? Would something like a Synology DS916+ suit my requirements or is that overkill? I could deal with a custom box but I'd rather save myself the hassle.
|
|
#
?
Mar 31, 2017 12:29
|
|
|
People have wanted to run everything under the sun on their NAS and FreeNAS finally integrated docker and bhyve support in the GUI. The new GUI also in theory supports multiple operations from multiple logins and and a CLI for their front end. These all sound like great selling points for TrueNAS appliances, why do people think they've lost their way?
|
|
#
?
Mar 31, 2017 16:26
|
|
|
thebigcow posted:People have wanted to run everything under the sun on their NAS and FreeNAS finally integrated docker and bhyve support in the GUI. The new GUI also in theory supports multiple operations from multiple logins and and a CLI for their front end. I think it's because surprise surprise, the greenfield complete rewrite of their UI feels less mature than their polished over the last decade solution. Corral will be great in 3 years time.
|
|
#
?
Mar 31, 2017 16:31
|
|
|
TTerrible posted:I liked 9 but the decisions in 10 are just baffling to me. Docker? Really? People have mentioned a few other strange regressions in behaviour. Watching people get mad because thing a) is more popular / new kid on the block than their preferred thing b) is always the cutest. If you can't understand the benefits (and drawbacks) of something being popular and accessible by a wider audience then boy oh boy.
|
|
#
?
Mar 31, 2017 19:14
|
|
|
Mr. Crow posted:Watching people get mad because thing a) is more popular / new kid on the block than their preferred thing b) is always the cutest. I use Docker at work. This isn't because I don't understand Docker or fear new things. I don't understand the advantage over BSD jJails on my NAS at home.
|
|
#
?
Mar 31, 2017 19:39
|
|
|
TTerrible posted:I use Docker at work. This isn't because I don't understand Docker or fear new things. I don't understand the advantage over BSD jJails on my NAS at home. One of the reasons that the FreeBSD team gave for it was greater maintenance simplicity going forward: apparently the jails available as plugins under 9.x required a dev to go in and hand-manage them every time there was an update for one of the jails. Utilizing Docker is supposed to virtually eliminate that, meaning things should be up to date more often, and allow a much wider selection of "pre-made" plug-ins available than in 9.x.
|
|
#
?
Mar 31, 2017 19:55
|
|
|
DrDork posted:One of the reasons that the FreeBSD team gave for it was greater maintenance simplicity going forward: apparently the jails available as plugins under 9.x required a dev to go in and hand-manage them every time there was an update for one of the jails. Utilizing Docker is supposed to virtually eliminate that, meaning things should be up to date more often, and allow a much wider selection of "pre-made" plug-ins available than in 9.x. Thanks for the normal, non-agro reply. I think the only pre-made jail I used was the transmission one, otherwise I spun up a few vanilla ones for my own uses. I didn't realise they sucked up that much time.
|
|
#
?
Mar 31, 2017 20:00
|
|
|
I'm just speculating here as I have no idea about FreeNAS and I have very minimal experience with BSD jails, but it feels like Docker will be better for the end user just by virtue of having a larger ecosystem of people working on docker and creating images, no?
|
|
#
?
Mar 31, 2017 20:03
|
|
|
TTerrible posted:Thanks for the normal, non-agro reply. They were sometimes slow to update as well and once in a while one of them would have been straight up broke and would be broke for days. I think transmission was the most recent one I can think of because it was built on a bad version of libtorrent or something to that effect that was universally banned and while the transmission maintainers were quick to fix, the plugin wasn't for a bit and the solution for the time was snapshot back to an older version, use a client on your desktop or waited because I believe transmission is the only BitTorrent client that has a plugin in 9 if I recall.
|
|
#
?
Mar 31, 2017 20:12
|
|
|
Thermopyle posted:I'm just speculating here as I have no idea about FreeNAS and I have very minimal experience with BSD jails, but it feels like Docker will be better for the end user just by virtue of having a larger ecosystem of people working on docker and creating images, no? Docker lets developers ship something wrapped up in a nice little package that they have full control over (which a lot of users like, since it means they have to do less work), but it can complicate certain other tasks like updating individual cogs of the docker image and it makes you rely on someone else to do the packaging of the container which can be critical in case of zero-day exploits, and it wasn't written with security and isolation in mind (though that has since added, my understanding is that it leaves a bit to be desired unless you really lock it down tight which affects usability). Jails originally only served to put the super user (root) in a container that they (or anyone else in that jail) can't escape from, so it's inherently very secure (although it has had some jailbreaks, since no software is perfect, they've been patched or are easily mitigated), but as a result it's more complicated for the end-user. If someone took the time to make the tooling with API similarity required for it, jails could function just like docker - it's just that seemingly nobody with programming skills or nobody with money has thought of it, and there's another way: Native Docker on FreeBSD has been made possible by making use of the Linuxulator (a Linux syscall compatability layer) that's found in -CURRENT which was recently aligned with upstream (Linux 4.10), so you still get the benefit of being on a FreeBSD kernel (with zfs, its scheduler and network stack, among other things) but without having to mess around with bhyve and boot2docker (and deal with the downsides of that). BlankSystemDaemon fucked around with this message at 21:18 on Mar 31, 2017 |
|
#
?
Mar 31, 2017 21:12
|
|
|
D. Ebdrup posted:Docker is containers for developers, jails are containers for sysadmins - and each have pros and cons. Right, I know what Docker and jails are. I'm saying that end users might have more stuff available for them when docker is used instead of jails...as long as what I'm imagining FreeNAS uses them for is correct. It's basically an easy way for people to run more software on their NAS, right?
|
|
#
?
Mar 31, 2017 21:16
|
|
|
Thermopyle posted:Right, I know what Docker and jails are. I'm saying that end users might have more stuff available for them when docker is used instead of jails...as long as what I'm imagining FreeNAS uses them for is correct. It's basically an easy way for people to run more software on their NAS, right? Yeah, that's been their stated goal for a long time with plugins - so hopefully they'll stick to this way of doing things and not migrate to the new way in -CURRENT and once again leave users stranted on an old system with no easy way to migrate.
|
|
#
?
Mar 31, 2017 21:19
|
|
|
Just got an error when moving files from one drive to another. So I ran CrystalDiskInfo for the first time in months. Those are 6TB combined, no backups. Just gently caress my poo poo up for the weekend why not. Sorry just had to went.
|
|
#
?
Mar 31, 2017 22:42
|
|
|
zebez posted:Just got an error when moving files from one drive to another. So I ran CrystalDiskInfo for the first time in months. No active S.M.A.R.T. checking while in your array?
|
|
#
?
Mar 31, 2017 22:57
|
|
|
8-bit Miniboss posted:No active S.M.A.R.T. checking while in your array? No array. And no active smart checking. Didn't know it was a thing. I'm not really asking for help or advice, I'm just showing my lovely situation for everyone else to make fun of.
|
|
#
?
Mar 31, 2017 23:11
|
|
|
zebez posted:No array. And no active smart checking. Didn't know it was a thing. I'm not really asking for help or advice, I'm just showing my lovely situation for everyone else to make fun of. 
|
|
#
?
Apr 1, 2017 00:33
|
|
|
zebez posted:Just got an error when moving files from one drive to another. So I ran CrystalDiskInfo for the first time in months. Well the drive (s) still shows up so you are doing better than you could be. If it were me I would start copying stuff off those drives now. If that isn't working you might need to use a Drive recovery tool.
|
|
#
?
Apr 1, 2017 16:51
|
|
|
Caution on its own means nothing. A single reallocated sector will cause this.
|
|
#
?
Apr 1, 2017 16:53
|
|
|
Combat Pretzel posted:Caution on its own means nothing. A single reallocated sector will cause this. Might as well light it on fire and rebuild from scratch.
|
|
#
?
Apr 1, 2017 17:02
|
|
|
redeyes posted:Well the drive (s) still shows up so you are doing better than you could be. If it were me I would start copying stuff off those drives now. If that isn't working you might need to use a Drive recovery tool. At least some files are corrupted beyond repair. Gonna have to shell out some cash for new drives. My amazement was that 3 drives are showing caution, when 6 months ago none were. And 2 of them are only "Caution [C5] Current Pending Sector Count: 1" and the 3rd one has way more (hundreds) errors. But still the corrupted files are on one of the drives with 1 sector error. ¯\_(ツ)_/¯
|
|
#
?
Apr 1, 2017 20:43
|
|
|
Thermopyle posted:I'm just speculating here as I have no idea about FreeNAS and I have very minimal experience with BSD jails, but it feels like Docker will be better for the end user just by virtue of having a larger ecosystem of people working on docker and creating images, no? Kubernetes is kinda winning out over Docker in terms of development/support at the moment because it's backed by Google and has similar functionality. Kubernetes is aimed a little more at AWS style deployments and the tooling is a bit rougher in some ways but it seems to be the trend at the moment.
|
|
#
?
Apr 1, 2017 23:58
|
|
|
Um. What? Kubernetes is an orchestration tool for Docker containers. Their own documentation explicitly calls out that the only container type that's supported is Docker.
|
|
#
?
Apr 2, 2017 00:51
|
|
|
|
| # ? May 24, 2024 23:58 |
|
|
Haven't looked too heavily into it, just repeating what I've seen elsewhere. I guess it's more comparable to Docker Swarm then.
|
|
#
?
Apr 2, 2017 02:07
|
|