NASLite Network Attached Storage

I like both of those suggestions and would like to raise one of my own.

As I have two large arrays which periodically require a boot-check (because I insist on switching off the server every night....), would it be possible to include a progress bar / percentage / eta to the "Checking storage filesystem [Disk-N] .................. [ BUSY ]" line? These checks take anywhere up to a bit over an hour and it would be nice to know when I can expect to get at the files on the server....

Alternatively, if the syslog rollover were to be introduced, the system uptime could be taken into account between disk checks rather than just every N boots.

I know we are now ... like totally ... off-topic, but ...

GREAT idea on the progress bar during fsck.

I also turn off every night. And what's been bothering me is the complete inconsistency of the "tune2fs" parameters on the three disks I have installed. Somehow I inherited maxcounts of 20, 35 and 31 (!) on a 300, a 400 and a 500GB drive.

So yesterday I finally got fed up enough that I created and booted a LiveUSB version (no CD in this system) of DSL (DamnSmallLinux) and forced a disk check on Disk-0, then set to check every four weeks ("tune2fs -c0 -i4w"). This means Disk-0 will be checked on Sunday mornings (when no one needs the file server early a.m. like the rest of the week) approx once a month (set it to any interval you like using "w"eeks). Next Sunday I'll do the same with Disk-1, then another Sunday later, Disk-2. This forces staggered disk checks, not all on the same Sunday; and I picked 4 because I might add a fourth disk soon. So, practically speaking one disk check happens just about every Sunday (but never again RANDOMLY during the work week unless forced by rare circumstances).

I know "tune2fs" is already part of NASLite ... how about a menu option to allow user-access to the parameters ?

Looks like I introduced a growing discussion. Cool..

This is the 1st NAS I have built. I've built 2 computers before it and I would label myself as a newbie. Even a 5 second delay as Tony mentioned would be helpful. I wouldn't need 30 seconds to read everything even as a newbie ( I know I said 30 seconds before). But having thought it over some more a Max 15 seconds. It isn't an absolute necessity but it would make it more user friendly in my opinion. I did the same thing Grasshopper mentioned at first, it rebooted when I wasn't looking as I am often distracted or multitasking with other things.

I do like the idea of pressing a key to reboot. I shutdown everynight as well.

OK, Ralph and I have been pondering this and here is the solution that sounds most appropriate to us:

1. Shutdown due to resource absence - we intend to issue an notice printed on the console alerting of the pending shutdown as well as the associated reason with a delay of 15 seconds.

2. Filesystem check at boot - we intend to perform the necessary maintenance at shutdown. That way, the filesystem should be clean at boot so no wait before mount.

any comments?

Minor concerns about unattended shutdown would be largely outweighed by convenience of never having to wait for a disk check on startup.

I can't think of any reason for concern at shutdown. The OS will just clean house before going down instead of at boot time.

Windows has failed to shutdown for me too many times to be totally comfortable with a PC shutting down unsupervised. That said, since my IRQ problems have been solved (about 2 years now), I have never had NASLite-2 or M2 fail to shutdown when required.

Concern I have with file check at shutdown is that sometimes you're simply re-booting due to configuration change. Also, occasionally, you're shutting down for a variety of special reasons (move the server or re-arrange something else, power-outage (little juice left on the UPS), etc). In any of these cases I would find an irregular file check (defined as one being required due to errors) or a regular check (programmed via tune2fs) at that time an inconvenience. I would prefer to control the regular file check per what I posted above (Sundays) at predictable times, and in those rare cases of a check due to real errors I'll just wait during startup ... it's also more likely that I actually will notice the irregular file check at startup, rather than at shutdown. My preference is to realize it's happening since it's an irregular check ... if it happens at shutdown (which in my case is automated and at or past bedtime) I may never find out about the fact that errors were present, requiring an irregular file check.
(Sorry if this reasoning seems confusing ?)
(Edit: NickC's post just popped up ... good term "unsupervised" file check at shutdown.)

Here's my 2 cents:

I agree with Georg. Although changing the fsck to run at shutdown as Tony suggested would allow faster access to file content on startup for those who regularly shut their nas down, a scheduled fsck makes more sense to me than counting number of boots. It really doesn't matter on my setup whether it happens at shutdown or startup because I never shut my nas down. The only time it is rebooted is for config/hardware changes or the occasional reindexing of the uPNP database, so I still have to wait for content if one or more of my drives happens to come up on the "magic number". For my 500G drives, this can take anywhere from 30 minutes to an hour.

Perhaps you could make fsck handling an option in configuration, selectable between counting number of boots and initiating at startup or shutdown, or configuring a time of day/day of week/day of month when fsck would be run automatically on a weekly/monthly basis?

I agree that a scheduled fsck would be the better option.

As I understand the boot process of NASLite, it renders the hardware afresh each boot - as it should. This does not, however, preclude the storage of pertinent operational data (uptime, throughput, etc) on the configuration device (if CD) or USB stick / CF Card / HDD / DOM / etc. every time the system shuts down. This is a tangent to the idea that syslog information should be stored. So, if the system has been up for, say, 90 days (over about a year ) it could schedule a fsck (and give advance warning / user deferment options, etc) automatically.

All are valid points really. It seems that no matter how it's handled, some concerns are addressed at the expense of others. So how do we keep things simple, robust and authoritative? Short of introducing a host of options ("time", "# of boots", "enable/disable" and "at boot/at shutdown") per filesystem, what would one consider to be the sweet spot for time interval and number of reboots?

Tony, you raise a good point and I understand the need for small, robust and simple. My reason for suggesting another (several?) config option(s) was because I realize that this answer would be different depending on who you ask (personal usage habits, individual desires, etc.). For what it is worth, I would suggest an automatic fsck initiated every 30 days with no boot count and forced fsck at boot for detected fs errors or improper shutdown. This still leaves the question of what time of day the timed fsck should occur. What would be a good time of day for me (3am) may be the time of day another user gets off from work and wants to watch/listen to content. From this standpoint, is there really a good answer for that? Would making another config option compromise the robustness or increase the size that much? Seems to me that it's more of a balance between complexity and user convenience that would need to be addressed. IMHO, sometimes simplicity needs to take a back seat if the proposed changes would improve the overall user experience.

But then, as someone once said, opinions are like (insert body part here): everyone has one

setting the frequency of the disk check is not that difficult - all things are possible - even turning it off i believe from a linux distro - but as someone who only boots the system when required having to wait for the check when it kicks in is a pain - so no time is a good time at boot up

but having it at shutdown would be for me a great option - however i can see that that would not suit all

would not a setting to change it from bootup or shutdown be the simplist option and an addition to the manual telling how to alter the frequancy if adding that function over complicates the software

Adding options is fine and dandy but where do you stop? if there are options added to the software, i think i'd want them in other places like the services or mirroring or scheduled shutdown or whatever else i happen to need at the time. Next thing you know you got 350 options and a total clusterf**k. I have to say it's kind of nice not to have to worry about all that crap when setting a naslite. So, i'd set the fsck to 6 months and 180 reboots and leave it at that. With ext3 and no live os running on the shares it should be just fine. That way it would happen on average once every 6 months and not piss people off.

I guess waiting for a keypress is not such a hot idea for those setups without a keyboard

The syslog idea is very good.