RasterEyes

I disabled the cache and all the problems went away, even the disconnect problem that doesn't make sense as having anything to do with the cache. Unfortunately backing up is a lot slower without the cache, but I guess that's the best I'm going to get unless someone knows a reason for my share connections getting dropped.

I'll take your word for it that NFS and caching don't get along, but these failures seem to be something much more. It's not like the mover is running or even gets a chance to run before those errors pop up. I completely lose the connection to the remote arrays in a short time, needing to unmount and remount just to re-establish a connection, and as soon as I run rsync the stale file handles are pouring in by the hundreds, well before the mover has any time to act. Could it be that Dynamics Cache Directories causes a problem, caching inode values that are inconsistent? I could live with the "stale file node" handles as just so much annoying noise, because, after all, it just seems to be a warning and data does get copied anyway. The much bigger problem is how the volume completely disconnects when rsync is done, and isn't connected before I run rsync unless I do an unmount/remount cycle.

Yes. Not that the mover is or has to be running at the time these problems occur, but these shares do use a cache drive, so eventually the mover will be activated. I hope that doesn't mean the only solution is not being able to use a cache.

I've seen this issue come up in some older posts, but I haven't found any useful advice yet. I have two Unraid arrays, main storage and backup. The backup array exports two NFS shares, and the main array automounts these two shares. Maybe I'd have better luck with SMB shares, but I want to maintain symbolic links which aren't supported by SMB. The problem is that even though these shares are automounted, they seldom work for my rsync backup unless I unmount then remount them each time before use, then use them right away after doing so. Here's what I see before the unmount/remount: rsync: [Receiver] ERROR: cannot stat destination "/mnt/remotes/my_share_name/": Stale file handle (116) rsync error: errors selecting input/output files, dirs (code 3) at main.c(772) [Receiver=3.4.1] rsync: [sender] write error: Broken pipe (32) rsync error: error in socket IO (code 10) at io.c(849) [sender=3.4.1] Further, even when the backup is working and writing to the remote share, I get a crapload of: default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask default_perms_for_dir: sys_acl_get_file(., ACL_TYPE_DEFAULT): Stale file handle, falling back on umask ...flowing down my screen as the backups proceed. Once the rsync backup is done, the remote share is immediately unreachable again without another unmount/remount cycle. There's nothing special about the way I've configured the shares: I've also attached diags for both arrays. Anything that can be done to make this more solid and reliable? trantor-diagnostics-20251025-2206-backup-array.zip terminus-diagnostics-20251025-2204-main-array.zip

I wanted you to know it's working great. With my array still steadily copying terabytes of data, in reconstruct write mode so every disk is spinning and busy with that task, I was able to watch 4K video steadily for the length of an nearly hour-long show without the slightest hiccup.

Ah, that makes sense (of a sort)! 😄

I've just about finished putting a lot of content on a newly built server. I'm a bit curious about the way the drive space has been allocated so far. It's 52TB of total available storage, as two 12 TB drives for parity, three 12 TB drives for data, and an additional two 8 TB data drives. Disk 1, 12TB, filled up to 6TB, then files started to be saved on Disk 2. Disk 2, 12TB, filled up to 6TB, then files started to be saved on Disk 3. Disk 3, 12TB, filled up to 6TB, then files started to be saved on Disk 4. All of that makes perfect sense. But then Disk 4, 8TB, only filled to one quarter of its capacity, just 2TB, before files were saved on Disk 5. Then Disk 5, also 8TB, only filled to one quarter of its capacity, just 2TB, before files went back to being saved on Disk 1. Why would the 12 TB drives fill to half capacity at first, but the 8TB drives only fill to one quarter capacity at the start? This was all from content saved to a single share with access to all disks, by the way.

And even though that's a single line, I can paste in a multi-line config? Perhaps like this? [video] # Do I repeat the path below, and everything else like security settings, or is that inherited? # path = /mnt/user/video # Do I repeat what was below, and then add on read_ahead? vfs objects = catia fruit streams_xattr read_ahead # vfs objects = read_ahead # Maybe this instead of the above? readahead = 65536 I have no idea if this would be treated as a total replacement of any previous [video] section, would inherit from it, appends or replaces with things like "vsf objects"... sorry this is so unfamilar and confusing to me.

I poked around some more to answer some of my own questions and found this at "/etc/samba/smb-shares.conf": [video] path = /mnt/user/video comment = browseable = yes # Secure public = yes writeable = no write list = foo,bar case sensitive = auto preserve case = yes short preserve case = yes vfs objects = catia fruit streams_xattr fruit:encoding = native Which makes my next question how (and where? in a different file) I modify this in a way that both doesn't conflict and is preserved between reboots.

Oh, I think I've got enough to go on. I was just curious to understand more so I'm not just blindly following a recipe. As a human you set me on the path of looking into SMB configuration. I'm not sure, but since I hadn't even considered that as part of a possible solution, I don't know if I'd have asked the right starting question to end up being directed to SMB configuration by an AI. Now that I'm thinking Samba, I asked this question: "How do I configure SMB to provide read-ahead for a particular share?" ...and got this answer: [YourShareName] path = /path/to/share read only = no vfs objects = readahead readahead = 128 # Number of kilobytes to prefetch (optional, default is 64 KB) ...which curiously disagrees on KB vs 512B block size, but, more of a cause for wonder, starts with "[YourShareName]" rather than "[media]". I guess you meant "[media]" as a sample name, whereas at first I was thinking "[media]" was a particular named subsection of smb.conf for a particular purpose, not a share name. I was also hoping to figure out on my own, without being a nag, what form the path here would take ("/mnt/user/video" perhaps, starting at the file system root?) on my Unraid system, and whether or there might already be a "[video]" section in some conf file somewhere set up by Unraid when I created my share, and if I would be running any risk of inappropriately overriding that if that's the case. The devil is can be in the details when wandering outside of one's own expertise, and SMB config files are definitely foreign territory to me.

One thing I must confess I'm baffled by is where you find all of this info. When I google with search terms like "smb.conf" and "read_ahead" I find nothing of use, unless perhaps the useful stuff is several pages into my search results. I'd be happy to figure out more on my own with the head start you have graciously provided, but damn, the info is hard to track down for me. I haven't, for instance, been able to find a single example other than the one you provided of a "[media]" section in a smb.conf file to better understand what that whole section is about.

This looks particularly promising. When you say I can restrict this to .mkv files, how would that be done? Wildcards in the path above, like `path = /mnt/user/video/**/*.mkv`? It would be good enough, even if it isn't strictly for .mkv files, for the read-ahead to apply to everything in the video share.

Thanks. I won't be able to experiment much immediately, as I've got a day or two until all of my movie content is restored to the new array I just finished building. It's too bad I can't restrict this kind of read-ahead caching by file extension to just *.mkv files.

Thank you! Very helpful. Would it be safe to go as high as 131072, 64MB, for roughly 30 seconds worth of HD video content? I've got "only" 16GB of RAM, but nothing else going on with the array other than being a simple file server, no Docker apps or the like.

True. What's now making the file transfer run a lot faster, however, is reconstruct write. That's 2-3 times faster.