Jump to content

One Page to Rule Them All - Better Disk Usage Information


jeffreywhunter

Recommended Posts

There are a couple places in the unRaid WEBGui and the unMenu utilities to get disk usage information - which are painfully slow and cumbersome to use.  It would be very helpful to have centralized/detailed information available on a page that provides a single location to get all disk/array/share usage information.  Currently, you click and wait for the system to slowly build the report which shows you most of what you want to know, but not in an easy-to-use way - and certainly not quickly.

 

At a high-level (I'd be happy to spend the time to work out more details/proposed screen shots if the community sees value in it - I do UI development professionally), the system should have the following features:

 

1. Directory information is pulled from the system and stored in a DB (optional 'frequency' for scheduled directory sweeps/updates - or even better, as files are added to the system, the DB cache is updated so you get a near real-time DB).  Then the array directory can display the system easily and quickly in a variety of controls.  I believe I read somewhere that there is already a directory cache somewhere in the system, perhaps that could be used?

 

2. This File Management Console (FMC) in the WEBGui could then provide a real-time interface into the file structure (without having to wait many minutes to get the data) which would be a central repository to display a variety of information (disk information (shares, used/free space, share/disk relationships, etc), file search (wildcards, etc), directory/file mover/delete/rename, etc).

 

All these (and more) features exist in the system, just not easy to get to use.  As unRaid looks to broaden the business model to appeal to the less technical, an application interface to manage files/shares/etc is important.

 

I'm sure there are other features that could be incorporated into this, but from a classic consumer user perspective (and hey, we'd all benefit from easier-to-use tools) a centralized FMC would be a significant benefit.

Link to comment

There is already a docker here for DUC, the replacement for philesight.

Personally I like the look of philesight a damn sight better, plus the DUC docker seems unsupported.

 

And in any case, this is about the base OS reporting of disk usage, rather than dockers.

Link to comment

Just a caution though, a prime feature of unRAID is its ability to keep drives spun down.  That is a factor that most or all of the tools mentioned do not take into account, and really complicates any new tool that would provide the desired file system reporting.  It doesn't make it impossible, but tool design will have to constantly keep it in mind.  Some users won't care about spin down, but many others will.

Link to comment

Just a caution though, a prime feature of unRAID is its ability to keep drives spun down.  That is a factor that most or all of the tools mentioned do not take into account, and really complicates any new tool that would provide the desired file system reporting.  It doesn't make it impossible, but tool design will have to constantly keep it in mind.  Some users won't care about spin down, but many others will.

True enough, keeping drives spun down is pretty important.

 

I wonder if the "cache dirs" and the disk usage  could be integrated (after all, cache dirs needs to maintain data on all the directories, so size is not a major addition?). I do feel that caching the data in some way would be smart - only refreshing totally when the drives were already spun up, but idle (or when commanded).

Link to comment
  • 2 weeks later...
Just a caution though, a prime feature of unRAID is its ability to keep drives spun down.  That is a factor that most or all of the tools mentioned do not take into account, and really complicates any new tool that would provide the desired file system reporting.  It doesn't make it impossible, but tool design will have to constantly keep it in mind.  Some users won't care about spin down, but many others will.

 

That is absolutely an important feature of unraid.  What I'd recommend is that the file system (prefer web gui, perhaps ajax driven?) that hits a database maintained on the server by unraid.  When a file is written/modified, the last thing the file system does is update the database with the appropriate information.  That way, you'd never have to hit the disk, ergo spun down drive, with real-time directory access.

 

I've read about keeping directories cached... http://lime-technology.com/wiki/index.php/Improving_unRAID_Performance#Keep_directory_entries_cached, so it appears to me that MOST of this effort is already done?  I would assume caching directory entries would be the database we want to hit?  Perhaps it would need a few extra columns...and an API to pass the info to a web page.  Would be a nice feature for 6.1...or a docker...

 

Looks like some other folks like this idea...https://lime-technology.com/forum/index.php?topic=39782.0.  And it looks like Aptalca created a container for Dolphin?  Don't know much about it yet.  Looks like there are some alternatives too...

 

Anyone used Aptalca's dolphin docker?

Link to comment

Unfortunately, CacheDirs won't help, and this would require new development.

 

CacheDirs is actually a VERY simple program.  A similar thing in Windows would be a batch file that runs 'dir' over and over.  It runs the 'dir' command on selected directories and their sub-directories, throws away the output, waits a calculated interval, and repeats.  Throw in some program control and you have CacheDirs.  All it's doing is accessing selected dir entries so that they won't age out of the kernels cache and have to be reread from disk.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...