This is the FIRST time I have done a firmware upgrade on my Drobo FS that had 1.0.1 stock firmware.
I used the dashboard to do the “web” firmware download and upgrade. After the reboot (the upgrade appeared to be successful), there is a NEW folder called lost+found. This folder is empty. The date attribute on the folder is from last year (not the date I did the upgrade).
Was this folder created by the firmware upgrade?
Was this folder (as judged by the date attribute) always there and just got unhide by the firmware upgrade?
Why does this folder appear now (I understand Linux has this folder as a root folder normally, but this was not there before)?
In a nutshell, you’re right that it’s completely normal, and you can safely delete it. I’ve had that show up once or twice after updates, and all it indicates is standard Linux/fsck housekeeping going on.
Interesting, so how about that folder does not exist when I first activated the Drobo out of the box? And why doesn’t the firmware upgrade process do the proper housekeeping and delete the folder afterward?
extfs has a mount-time option to fsck every X number of mounts, or after X many days. fsck creates that folder to hold any orphaned file data, and does not remove it.
It’s possible that your DroboFS hasn’t been rebooted in a while, or that it just now hit the limit of mounts and finally forced an fsck.
You’ve already gone to the expense and effort of using a RAID-like system, presumably to protect your data. I don’t believe you now want to disable filesystem integrity checks just to save the effort of deleting a folder once in a while.
I also don’t believe that such a feature-to-remove-basic-safety-features is popular enough that Drobo would make it a priority for future updates.
So does this firmware update that I made through the Drobo dashboard always create that folder? For those who had done the same update through Drobo dashboard, had your own updates always created the same folder?
I took interest in this because I am a newbie and want to learn more about this feature on a machine that I rely so heavily to store my data. Curiosity, I suppose.
If indeed that this folder was triggered by the filesystem check that itself was set off perhaps by the firmware update I just did, how come the “date” associated with this directory was dated last year (2011), more than a year ago from the time I did the firmware update (which I did only days ago)?
This suggests that the folder had existed for a long time. Is it possible that it became unhidden with the firmware update? As a sign that somehow the file attribute system is messed up.
It also may be a sign that when the check was performed, it was early enough in boot that the clock wan’t synced yet. I’ve seen weird date-time values get spit out by operating systems early in the boot process.