HDD Spin Down

[mirisbowring]

Heho, I am using unraid with many drives. The advantage is to automatically spin them down.
My question: Is filebrowser "silent"? meaning, that i can point it to e.g. the array and it spins up only the needed drives and if no access is there, that the disks can sleep because no index or hashing or stuff like this is happening in the background?

Thanks!

[gtsteffaniak]

filebrowser does actively spin up the drive for indexing. If theres no activity, then this indexing happens less often. But right now the scheduler is not too coordinated and each folder gets its own schedule and they dont yet synchronize. I was thinking about this issue specifically for hard drive wake cycles.

v2.0.0 will come with a new indexing scheduler that will coordinate the wake events, giving hard drives a longer period of spin down sleep time.

But currently, it should still work just the same. if theres truly no activity on the drive (no files changed), then the indexing will only happen once every few hours (as little as once per 12 hours).

[mirisbowring]

Hi, thanks for the info!
Wouldn't it make sense to listen to the inotify events only? E.g. (in context of unraid) if a user modifies a file, this disk will spin up. By listening on this event filebrowser could then Start indexing because this drive is running anyways. BUT filebrowser does not now about the hdd itself.
So starting indexing for "all" would then start all drives

[gtsteffaniak]

You might want to read this for reasons inotify isn't possible, its an outdated wiki, but thats a good explanation for the requirements for something like that. Its not designed to watch every single folder, just certain ones.

( And btw fsnotify/inotify would keep the disk active as well )

No plans to change how indexing works other than the more efficient scheduling. This form of indexing has been battle tested for years and alternatives have been investigated.

[mirisbowring]

Thanks for the info! Good read.

[chrneu]

@gtsteffaniak: I looked up the wiki but it seems the page does not exist anymore. Just wanted to give you feedback. I think filebrowser quantum is great and the way and speed you develop it. The only thing what I was wondering was indexing on every restart. So how I understand it, filebrowser quantum would do its initial indexing and storing it in its cache. The cache is invalidated at some point, good. But after a restart I would expect to reuse the current state. I am not an expert of inotify and how it fits into unraid, but I would assume to use native filesystem change detection functionality. I think you said that you would reimplement the scheduler. Maybe if a user could set the schedule, this would help decreasing wakeup times.

[gtsteffaniak]

it does reuse the index on restart, but always begins a new scan as well.

Youre right the old docs were deleted, I will update the new docs with the information, heres what it used to say which is still valid.

Why does FileBrowser Quantum index the way it does?

The smart indexing method uses filesystem scanners because it allows a low-footprint design that can cater to individual filesystem complexity. There are a few options for monitoring a filesystem for changes:

1. Option 1: Recursive Traversal with ReadDir

• This is quite computationally intensive but creates an accurate record of the filesystem
• Requires periodic scanning to remain updated
• Low overhead and straightforward implementation.

2. Option 2: Use File System Monitoring (Real-Time or Periodic Check) such as fsnotify

• This allows for event-based reactions to filesystem changes.
• Requires extra overhead.
• Relies on OS level features and behavior differs between OS's
• Requires OS-level configuration to ulimits in order to properly watch a large filesystem.

3. Option 3: Directory Metadata Heuristics.

• Using ModTime to determine when directory structures change.
• Has minimal insight into actual file changes.
• Much faster to scan for changes than Recursive transversal.

Ultimately, FileBrowser Quantum uses a combination of 1 and 3 to perform index updates. Using something like fsnotify is a non-starter for large filesystems, where it would require manual host OS tuning to work at all. Besides, I can essentially offer the same behavior by creating "watchers" for top-level folders (a feature to come in the future). However, right now there is a single root-level watcher that works over the entire index.

The main disadvantage of the approach is the delay caused by the scanning interval.