I'm thinking out loud here for others to comment on.

Sometimes I feel the first page should have less control but yet more information available.

 

if I were to redesign the first page, I would move the command /control buttons to a different control or mamangement page.

or possibly show it, but only if you are in advanced admin mode.

 

This first page should auto refresh.

 

First box would be overall Array status/ Health, Parity Check/Resync Status.

Any failure condition here would result in a status pertaining to general health of the environment.

No buttons here. That belongs on a management and command status page.

(Unless a check box is enabled for advanced control mode or something like that).

 

Next Box would be some configurable display of the last X lines of syslog.

Messages in the syslog area should be colored according to configurable regex's.

How this data is not displayed somewhere on the ui disturbs me (With all due respect, I have to be honest here too).

 

Next box would be a filesystem size and health display like DF

root@unraid:~# df -vH

Filesystem            Size  Used  Avail Use% Mounted on

/dev/sdf1              518M  176M  343M  34% /boot

/dev/md2              501G    34M    501G  1% /mnt/disk2

/dev/md1              501G  142G  359G  29% /mnt/disk1

shfs                      1.3T  145G    1.2T  12% /mnt/user

tmpfs                    1.1M      0      1.1M  0% /unraid

/dev/sdd1            251G  3.0G    248G  2% /mnt/disk3

 

There would be hyperlinks on the /mnt/disk lines which would access a web based file browse mode.

 

Next box would be as current with the Disks shown and their true SMART health (Which is something the readyNAS shows).

Along with this might be the output of some data from LM_SENSORS.(Perhaps LM_SENSORS first, then disk status).

I would also like to see which /dev/sd? or /dev/hd? device this drive resolves too.

Perhaps you could also have The filesystem size.and disk free and such, but that may make this page to busy.

 

 

There would be hyper links on the drive id's to another "drive" specific page.

 

Here I would duplicate information about the drive.

Where the hardware resolves to (Not normally needed, but it's sometimes good to know when drives move around).

Filesystem usage as in DF.

PCI Device assignment (but not changable, this is only for documentation purposes).

 

Here you would have access to managing a single drive. Feature modes such as.

SMARTLOG REVIEW

SPIN UP

SPIN DOWN

CONFIGURE AUTO SPINDOWN TIME.

MOUNT

UMOUNT

Reiserfsck

SCHEDULE Reiserfsck on next reboot before array is put online.

INITIATE SMART TEST(Short/long)

NOTES

Identify (sometimes you need to see where it is in the array)

BADBLOCK TEST

CLEAR

Lots of great ideas here.  Sorry for no bites on the first cast, but I've had a tab open to this ever since you posted.

 

My constant thought as I traveled through it though, is that you probably could not find any 2 people who could agree on how it should look, or what info should be on the top page.  If unRAID users were plotted on a 4 quarters graph, with the vertical scale being users from the newest non-technical to the most advanced and experienced, and the horizontal being the user preference for minimal info to maximum info on one page, there would probably be users widely spread across all 4 quadrants.  The whole thing clearly cries out for a user-configurable approach, but that brings up a lot of choices and questions.  I suspect others sensed this, and did not want to open up the can of worms.

 

Whatever finally comes of this, the ideal solution should have both extensive configurability and pre-configured default setups, of a brief/standard/full nature (or perhaps lean/classic/advanced).  The application interfaces that seem most analogous are the various media players out there, and I think much could be learned from them.

 

The obvious approach is a skinning interface, with prebuilt skins shipped with the release, but this requires too much upfront development, to create the whole skinning infrastructure.

 

The idea I like best is a widget approach, with configurable widgets for all of the classes of unRAID info (including custom info), which anyone could then select and drag and snap wherever they choose, and individually configure.  But this too requires too much development effort upfront, to create the widget architecture (I think).

 

A tabbed interface is easier to create, easy to understand and manage, but I don't really care for it, as you can only have one tab open at a time.

 

A page similar to the current but full of links to all of the other info would be the easiest to create, but again you are limited to only seeing what is on the currently viewed page.

 

Perhaps the best choice then (in my view) would be the use of those show and hide indicators/buttons/slides, like some media players that show one main window with only the most general and required info and status indicators and perhaps a bit of summary info (all fully configurable at some point), but with a click or drag, open up more boxes/windows, a pseudo widget-based scheme.  So each user could have as little or as much open as they want.  This makes a lean/classic/advanced scheme very easy, and with prebuilt schemes provided, should satisfy both the newest and non-technical user as well as the advanced and experienced user.

 

There's so much more I could say, more of my own ideas, as well as comments on many of the specifics you mentioned, but I'll pause here.  I think I've stirred the pot...

My constant thought as I traveled through it though, is that you probably could not find any 2 people who could agree on how it should look, or what info should be on the top page. 

 

I agree, at least if we open the discussion on what is needed, (and POSSIBLY where) then ideas can form.

 

As cool as it is with having clickable enabled widgets. My thought is how long would it take to implement that vs a tabbed approach where users could install plugins for new tabs?

 

Another thought is... What widgets or bits of information is needed.

Lets refrain from where they go at the moment.

Let's at least identify what is needed to enhance overview and support.

 

X amount of lines of syslog (should this have regex filters to pick out/colorize error conditions?)

 

I would really love a drive detail and control page (Which is separate from the widgets, yet each control option would sort of be a widget in itself).

 

What else is needed (I proposed some segments below).

 

 

 

My constant thought as I traveled through it though, is that you probably could not find any 2 people who could agree on how it should look, or what info should be on the top page. 

 

I agree, at least if we open the discussion on what is needed, (and POSSIBLY where) then ideas can form.

 

As cool as it is with having clickable enabled widgets. My thought is how long would it take to implement that vs a tabbed approach where users could install plugins for new tabs?

 

Another thought is... What widgets or bits of information is needed.

Lets refrain from where they go at the moment.

Let's at least identify what is needed to enhance overview and support.

 

X amount of lines of syslog (should this have regex filters to pick out/colorize error conditions?)

 

I would really love a drive detail and control page (Which is separate from the widgets, yet each control option would sort of be a widget in itself).

 

What else is needed (I proposed some segments below).

 

 

 

Any approach to this issue is a major re-work for Tom.  This is because the presentation logic (html, style sheets, graphics) is in the same executable (emhttp) as the array management logic.

 

I might suggest an eventual change to emhttp that implements an API of some kind.  This might be implemented in parallel with the existing functionality.   The presentation logic that displays the data to the user can be a separate process that evolves over time, modular as needed.  The core control functions to start, stop, add disks, clear disks, remove disks, assisgn disks, validate keys, etc would have nothing to do with the code that generates HTML sent to a browser. The core control process would communicate via the API with whatever presentation logic is desired.  If somebody were to install Apache, they could have their own array control panel, styled as they require, including web-pages to whatever is needed for their server (asterisk, bittorrent, etc)  their pages would only need to know how to access the API to the control process.

 

All of this is a HUGE amount of work for Tom, and truthfully, at least in my opinion, adds little value to most installations.   I personally don't sit there looking at //tower/main.html.   I really don't care if it uses tabs, or pages, or widgets to display various classes of information.  I watch movies, and listen to music, etc.   My focus is on the media stored on the server, not the server itself.   The separation of the control logic and the presentation logic with an intermediate API does allow others on this  forum to assist in the presentation rework.   

 

Today, only Tom has the ability to make changes to emhttp (necessary to keep his proprietary work secure) and as simple a request as changing the label on a button can take months to be important enough to find its way to the top of the laundry list.  (hint-hint )   I would love an API to emhttp of some kind.  It can use any interprocess communication as Tom thinks appropriate.  (Named pipes and user-signals are easier to interface to from various programming languages than shared memory and semaphores) 

 

Optimally, emhttp could use something like /proc for its communications, but I'm not sure if a user level process can use /proc.  Perhaps emhttp could become a kernel level process, as long as the presentation logic (HTML) was in a user process.

 

Enough rambling.   We need UPS support, e-mail alerts, alternate file-system support, NAS support, and a re-labeling of the "Restore" button all before the //tower/main.html page is re-designed.   Now that bugs seems to be squashed....(I'm not aware of any other than minor annoyances) time to start back on the laundry list.

 

Joe L.

We think alike.

I've been thinking the same idea of a control process and a presentation process.

I think it's the right way to go, but as mentioned, a large undertaking.

 

As far as API, a simple telnet interface, "documented" http post calls, or an XMLRPC interface would suffice.

I've been playing with an XMLRPC daemon after playing with rtorrent and the XMLRPC interface.

 

At the very least separation would allow us to create CGI's to the API from a regular webserver (lighttpd or apache).

 

As an intermediate Perhaps the "skinnable" interface or adding CGI functionality within emhttp would work.

 

I know there is the laundry list.

 

Part of the purpose of this thread was to see what other information people think should be presented.

Which is why I made reference to the syslog segment.

 

I;ll go here again, if emhttp could do external CGI's we could develop our own plugins.

 

For instance. If a emhttp used a root directory whereby each subdirectory became a tab at the top.

Then it allowed us to serve html and was smart enough to run index.cgi as a default, we could drop in our own assistor plugins.

 

I've been contemplating this functionality with lighttpd, which is why the roadmap sort of became important.

I would not want to duplicate effort or waste time anywhere.

 

I suppose the laundry list is more important, but it doesn't hurt to discuss ideas.

 

 

Well... we still need emhttp to do anything fancy, but I figured I give everyone a peek at my latest addition to my unRAID server.   

 

Here is my own customized web-based management page (currently running on port 8080).   

 

Now for the cool features:

• It shows total space for all drives.
  
• It shows mount points
  
• It shows Linux devices
  
• It has a link to download the entire syslog
  
• You can browse/scroll the last 500 lines of the syslog on the screen.
  
• It has NO "Restore" button at all. 
  

.

 

No extra web-server was installed.  In fact, it uses NO extra packages at all.  I'm not using "Apache" or anything like "emhttp" that had to be compiled, or any program that had to be installed extra.  In fact, I'm using only what Tom supplied in the stock distribution of unRAID.   

 

I've not yet written the "Disk Management" page, other than the top menu... What would be useful there.   I'm thinking hdparm output, vol_id, smart output are all possibilities.   I'm thinking of one line of buttons per disk, each with a command to run, and a common output area to write to.

 

The "Array Management" page is functional and can Stop the array and Start and Stop Parity Checks. 

 

There is no ability to manage the devices, clear or format disks, or initially start the array.  I'll leave those things to the real emhttp, otherwise Tom would have nothing to left to do on the laundry list once the "Restore" button is re-named in his version.  :) :) Besides, those are the really hard things. 

 

Joe L.

(extra points will be awarded to the geek among us who figures out how I did it.  No... I did not hack or patch emhttp either    It was written entirely using the "vi" editor on the unRAID server and it is not a compiled program, because unRAID does not come with a compiler    At present it is about 360 lines of code.)

 

 

Here is the "Array Management" page.   

 

I'm thinking of adding buttons to Start and Stop Samba.

 

Joe L.

 

While checking parity... status is highlighted in RED

I really like what I am seing here, those screen shoots are awesome; informations on main page are really great and informative. Wonderful Joe!!! 

(extra points will be awarded to the geek among us who figures out how I did it.  No... I did not hack or patch emhttp either  Grin  It was written entirely using the "vi" editor on the unRAID server and it is not a compiled program, because unRAID does not come with a compiler  Tongue  At present it is about 360 lines of code.)

 

What about a fancy shell script capable of being called from inetd ?

 

Looks good Joe.

 

One suggestion, One the syslog view.

I think it might be better to have the link on the side as one long contiguous line above or below the syslog window.

This allows the syslog view to span the whole width of the page.

(extra points will be awarded to the geek among us who figures out how I did it.  No... I did not hack or patch emhttp either  Grin  It was written entirely using the "vi" editor on the unRAID server and it is not a compiled program, because unRAID does not come with a compiler  Tongue  At present it is about 360 lines of code.)

 

What about a fancy shell script capable of being called from inetd ?

No... I did not use inetd at all, and it is not a shell script.

Looks good Joe.

 

One suggestion, One the syslog view.

I think it might be better to have the link on the side as one long contiguous line above or below the syslog window.

This allows the syslog view to span the whole width of the page.

I originally had it span the whole screen.  It was a waste of space as most entries in the syslog a use less than half the width.  There was so much unused space that you did not even notice the scroll bars on the far right.  Making it less wide frees up some space for other content.  The few syslog lines that are longer than the available width automatically wrap within it as seen in this screen capture:

I've also made a tiny change and added a "Total" label to the left, and a line above the disk space totals, to make them more visible.  I can now clearly see I am at 76% capacity of my server.  It's OK, I can swap out the smaller 250G drives for larger as space gets tight.

 

Joe L.

Superb work. You got to tell us how it works

 

I have some suggestions, as most people likely will, feel free to ignore them I know the frustration of suggestions when in alpha development.

 

In no particular order:

 

Your start/stop samba is an excellent idea. I would also suggest a restart samba option for minimal downtime.

I would like to see a screenshot when disks are asleep to get a feel for how that looks.

Show all disks available but not assigned on the main page as well. I often have a disk in the machine that are not in the array for one reason or another.

Personally i am not a fan of scroll boxes. I tend to think a set number of entries with a button to see xx more or all makes more sense. perhaps that just my browsing style though.

Show the current highwater split level. I have no clue where this is stored but its a vital piece of information to get a feel about how the allocation is working.

A duplicates page. I often find that i have alot of duplicates detected in my syslogs. I can easily find them using the command line but most non linux users probably cant. Perhaps this might be better suited to a dedicated syslog page with some predefined filters to show interesting things which we can expand on in time.

Temperature is king in my world since i have a cooling problem. Perhaps we can cater for that in some way?

Download complete syslog as either text or gz. My syslog after 3 days uptime is almost 20MB so compression will be needed for most and standardising this would be good. On a similar ilk name the syslog with the box name and timestamp.

 

 

I wont post too many ideas this early in the day.

 

Obviously I would be keen to test this

 

Superb work. You got to tell us how it works

 

I have some suggestions, as most people likely will, feel free to ignore them I know the frustration of suggestions when in alpha development.

 

In no particular order:

 

Your start/stop samba is an excellent idea. I would also suggest a restart samba option for minimal downtime.

Good idea,

I would like to see a screenshot when disks are asleep to get a feel for how that looks.

Currently, it would look the same.  I'm not displaying any indicator when spinning/sleeping at this time.   I think the hdparm command can return sleeping status. I'll investigate.

Show all disks available but not assigned on the main page as well. I often have a disk in the machine that are not in the array for one reason or another.

Good idea. I can compare the drives listed in /proc/mdcmd to those in /dev/disk and show those not yet assigned.

Personally i am not a fan of scroll boxes. I tend to think a set number of entries with a button to see xx more or all makes more sense. perhaps that just my browsing style though.

I did not want to have to scroll the main screen at all. You can always change it.

Show the current highwater split level. I have no clue where this is stored but its a vital piece of information to get a feel about how the allocation is working.

Isn't that set per share?

A duplicates page. I often find that i have alot of duplicates detected in my syslogs. I can easily find them using the command line but most non linux users probably cant. Perhaps this might be better suited to a dedicated syslog page with some predefined filters to show interesting things which we can expand on in time.

Not a bad  idea for a separate page.  It will free up some space on the main page for those with 17 drives in their array.

Temperature is king in my world since i have a cooling problem. Perhaps we can cater for that in some way?

I think that is available from the smartctl command.  Don't know where else that is available from the unix command line.

Download complete syslog as either text or gz. My syslog after 3 days uptime is almost 20MB so compression will be needed for most and standardising this would be good. On a similar ilk name the syslog with the box name and timestamp.

First, something is fundamentally wrong if your syslog grows that fast.  Mine  hardly grows at all.  The idea of compression is a good one though, once the syslog gets over a given size it would be useful... it is MUCH harder however, as it is binary data.  The method I am using to serve up the web-pages is really only useful for text.  It is why I color coded the disk status rather than showing graphics. (another binary object type)  I can add a button to copy a dated.gz copy of syslog to the flash drive.

I wont post too many ideas this early in the day.

Obviously I would be keen to test this

Soon enough. 

 

Joe L.

You guys are amazing.... thank GOD you are so interested in unRaid 

 

Can't wait to get my hands on this !!! 

 

 

(extra points will be awarded to the geek among us who figures out how I did it.  No... I did not hack or patch emhttp either    It was written entirely using the "vi" editor on the unRAID server and it is not a compiled program, because unRAID does not come with a compiler    At present it is about 360 lines of code.)

 

I can see the need for an editor that is much easier to use for those who do not want to learn "vi," but since I've been using "vi" since the early 80's, I've gotten to where I install it on windows, as it beats almost anything out there for many tasks when programming and editing text files.  You can learn vi in a few minutes, and master it in a few years. (it is that powerful that most people do not know all of its capabilities... it can even make coffee, well close :-))  I used to know most of what it could do, but features have been added over the past 20 years or so.. so even I do not know everything it can do any more.

 

Just a guess here (any points for guesses?), you are using something built into vi, macroing/scripting/page generation/port listening/etc.  I don't personally know anything about vi, so I may be way off.

 

Since this may be creating a small pseudo 'web server' on the unRAID server, using just what comes with unRAID, is there a potential security vulnerability here?

Joe some comments on your comments.

 

The syslog thing was my fault and also an unraid bug/feature. I broke my cron.daily so no log rotate. That explains most of it. However syslog is crammed full of shfs duplicate file entrys. This is a historical thing based on swapping drives and adding a duplicate drive with mostly the same data but it generates thousands of logs. A couple of backup family picture directory's could easily cause this to get out of control.

 

Highwater: suppose it must be per share since a share could have excluded drives. Not sure where or how to check this but i have a sneaking suspicion it will be useful when we do.

 

I am making the assumption that you dont want to add any packages and rely solely on what uNRAID ships with. If so i can see your reasoning but i predict it wont be long before you make things hard for yourself. For instance with HDDtemp you can parse smartctl but it is so much more trivial to use hddtemp. This isnt included though so once you know your design premise we can temper our suggestions accordingly.

Looks great, Joe L.!!  You da man!

 

However it's done, it certainly looks like fertle ground for improving the usability of unRAID!

 

Thanks for all the hard work on this!

 

Maybe you should bring back the restore button, so we'd all have something to complain about! 

(extra points will be awarded to the geek among us who figures out how I did it.  No... I did not hack or patch emhttp either    It was written entirely using the "vi" editor on the unRAID server and it is not a compiled program, because unRAID does not come with a compiler    At present it is about 360 lines of code.)

 

I can see the need for an editor that is much easier to use for those who do not want to learn "vi," but since I've been using "vi" since the early 80's, I've gotten to where I install it on windows, as it beats almost anything out there for many tasks when programming and editing text files.   You can learn vi in a few minutes, and master it in a few years. (it is that powerful that most people do not know all of its capabilities... it can even make coffee, well close :-))  I used to know most of what it could do, but features have been added over the past 20 years or so.. so even I do not know everything it can do any more.

 

Just a guess here (any points for guesses?), you are using something built into vi, macroing/scripting/page generation/port listening/etc.  I don't personally know anything about vi, so I may be way off.

 

Since this may be creating a small pseudo 'web server' on the unRAID server, using just what comes with unRAID, is there a potential security vulnerability here?

Not using vi, other than to edit the script.  I could have used notepad in windows to create it if I wanted, but vi is so much more powerful an editor for programmers.

 

Yes, excellent point about security.  There is none. 

 

It is a program listening on a port.  I'm sure it is not perfectly secure, anybody can invoke it and stop the server, and have no idea if it would be possible to feed it data it could not handle. 

 

Odds are it might be crashed if you feed it huge querrystring parameters, but, perhaps not.  Since I do not allocate memory I can only guess if it is possible to overflow a buffer.  The program itself has been around forever in unix, but fairly recently in Linux it gained the ability to access network ports.  It did not have that ability when I first learned it many years ago.  It is a very heavily used utility in unix/linux, so odds are its memory allocation is pretty decent.  Looking around using google I found almost NO examples of others using its networking capability.  The only ones I found were in the initial white-paper describing the newly added features. 

 

I'm just trying to push the envelope a bit with this utility without having to have a person load additional packages on their server.  As it is, my script based web-server is a single interpreted text file you can invoke on the Linux command line.  I stop it using "CTL-C"  I've never even tried to run it in not connected to a terminal. (odds are it will work just fine)

 

The new "web-server" is a great rapid development tool in that I can get feedback from people like yourself and incorporate the best of the ideas.  I've learned it is much easier to show a skeletal version of a program to an end-user and get their feedback and suggestions.  Some suggestions will not be possible, some will, some I just did not get to yet.  Yes, I could have installed Apache, or one of the lightweight http servers, but I wanted to do it the hard way.  Trust me, this is not a web-server for a high volume web-site.  It is not going to put Apache out of business.    Besides, most people would have a tough time installing and configuring a full size web-server on their unRAID server.  Some would be unwilling.  This eliminates the need for any additional package.

 

Internally, my script does invoke the "/root/mdcmd status" command, the "date" command, the "/root/samba" command, the "umount" command, the "tail" command, the "strings" command, the "uname -n" command, and the "df -H" command.  Basically, I'm parsing their output and formatting it into HTML for display.  To show spin up/down status and temperature it looks like I'll be adding "hdparm" and "smartctl" to the programs that are expected to exist. (somebody trying this on an older version of unRAID might need to install smartctl if it was not included)

 

Some suggestions will not be in an area I'll want to even try.  I won't even attempt to use it to configure the unRAID server, or to clear/format/assign disks. It will just to report and do basic admin tasks not currently possible.  It will potentially give Tom a few ideas (he is welcome to borrow some or all)  I do not want to replace emhttp, just supplement it. 

 

For the drive temps, I can parse smartctl output easily, just as easy as using hddtemp.  Both will spin up the drive though, so I first need to check the spin up/down status using hdparm -C anyway.  It will be a two step process for each drive in the array.

 

My goal was just to do this for fun, and to build it in a way that other geeks like me can extend if they wish to add their specific pages to monitor their specific custom packages via the web.  Once you see how to do it, you can add a new page too.. (as long as you know a bit of html and programming logic)

 

Joe L.

Looks great, Joe L.!!  You da man!

<snip>

Maybe you should bring back the restore button, so we'd all have something to complain about!   

If I do, I'll be sure to name it something other than "Restore" 

 

Joe L.

Joe hddtemp will only spin a drive up if you specifically tell it to. It also caters for weird SMART implementation via an updatable dbase of drives. These are the two reason i use it. Just an FYI.

 

The one problem i see with your work Joe is that people are going to inudate you with a load of basic stuff that should be in the official GUI anyway. In essence your going to be a victim of your own success

[me=NAS]starts a HUGE request list for Joe lol[/me]

Joe some comments on your comments.

 

The syslog thing was my fault and also an unraid bug/feature. I broke my cron.daily so no log rotate. That explains most of it. However syslog is crammed full of shfs duplicate file entrys. This is a historical thing based on swapping drives and adding a duplicate drive with mostly the same data but it generates thousands of logs. A couple of backup family picture directory's could easily cause this to get out of control.

I see...  I like this so much a separate page showing a filtered list of the shfs duplicate files listed in /var/log/syslog is in order.  Thanks for the suggestion.

I am making the assumption that you dont want to add any packages and rely solely on what uNRAID ships with. If so i can see your reasoning but i predict it wont be long before you make things hard for yourself. For instance with HDDtemp you can parse smartctl but it is so much more trivial to use hddtemp. This isnt included though so once you know your design premise we can temper our suggestions accordingly.

I already answered this, but I need to parse the output of any command I use to get the temperaature and it is as easy for smartctl as it is for hddtemp.  Since smartctl is included, I'll use it.

 

Joe L.

Time for a few updated screen shots...  I'm now at 600 lines of code.

 

I've added in drive temperatures.  If the temp is "*" the drive is spun down. 

If the drive temp is over 40C, it is highlighted in yellow, if over 50 in orange, and if over 60 in red.

 

I added "unassigned drives" on the main page and moved the syslog to its own page.  I do not have a cache drive.  Odds are it will show up as unassigned since it exists, but not part of the "md" array.  Can one of you with a configured cache drive look at your /boot/config/disk.cfg file and see if there is an entry in it for the cache drive.  If so, what does the line look like?  I'm expecting something like "cache=......"  If you can let me know I can code it to exclude the cache drive from those unassigned.  If it is not there, perhaps it will be visible in the output of the "mount" command.

 

I added buttons to stop and re-start samba, also to reload the samba control file (potentially with updated content)

 

I added a "dupe files" page.  Note, the files MIGHT be duplicates, or might just have the same names.  They are the files that the user shares finds on multiple disks with the same name.  Only one is shown in the user shares, Investigate before deleting one or the other from the "disk" shares.

 

Once I put some content on the "Disk Mgmt" page I'll share the program itself and the fellow geeks following this thread can play with and extend it for their own needs.  So far, "Disk mgmt" is empty except for the top of screen status and menu.

 

Joe L.

 

Main page

 

Array Mgmt page

 

Disk Mgmt page

 

Syslog page

 

Duplicate Files page

 

Keep it up Joe. It looks great. Thanks for the hard work.

 

Phil

Totally great! Indeed - thanks for the hard work... I like the "duplicate files page".

 

More power to you Joe!

Nice work on the duplicate finder. I have something like 10,000 duplicate files so syslog is exploding.

 

Also nice work on the tempertaure view, superb.

 

Next idea:

 

Show the disk spin down settings for the drives (unRAID not turned on this now so cant check). The official unRAID has a scattergun approach of settings all drives the same but I can see scenarios where it would be better to have finer granularity. Stage one would be visibility of the per drive settings.

 

Also have you considered a cron job to precache alot of this info. What I am thinking is that with a cron job logging stuff you start to get some cool stats like: How long since last drives was spun down, how much data has been transferred in the last hour, whats the temp increase of this drive. Once we have the data the data manipulation and presentation options are limitless.

 

Would it be possible to show the size and possibly time/date fileds of the dupe files so we can avoid tracking down "different" files with the same name?  My music collection is up to near 4tb's now and there are a LOT of folder.jpg files!!!  Better yet, how about not even showing them if they have different sizes...