NASLite Network Attached Storage

Hello:

Just installed a brand new Segate 500GB 16MB buffer SATA II (3G/s).

This is my config: older Seagate 200GB on IDE0 Master (IDE-0-0-0-0); Maxtor 300GB on IDE0 Slave (IDE-0-0-1-0); New Seagate 500GB on SATA1 (SCSI-1-0-0-0). The USB stick is Disk-3 (SCSI-3-0-0-0)

After first boot (of course) the Unlock code was no longer valid. I went to format the new (Disk-2) HDD anyway. Then did an export (RW), and a reboot (option 7 on main menu).

On restart Disk-0 was clean, but Disk-1 took 13 minutes to do an fschk. WHY ? (Note that this disk was my highest numbered BEFORE formatting Disk-2 and rebooting.) Nothing else was accessing the drive. Also note that I am used to fscheck (in version 1.5) taking much longer (hours) for this 300GB HDD with 114GB used.

I then did a manual read-only check (option 5 on Disk Config) of the new Segate (Disk-2) … did not take too long. I noticed that options 3 and 4 (S.M.A.R.T. related) are “*” on this menu for Disk-2. I figured it’s due to old Unlock code. I also did an option 7 (apply jounal).

I obtained a new Unlock code, and saved the config. The whole process since last reboot was maybe 5-6 minutes. I rebooted again.

On restart Disk-0 was clean, as was Disk-1, but Disk-2 took 1-2 minutes to do an fschk. WHY ? (Note that this disk was my highest numbered disk after saving config and rebooting.) This Disk-2 should have been CLEAN !

Options 3 and 4 are still “*” on this brand new 500GB SATA II disk … WHY ? (Status page for Disk-2 says SMART is UNAVAILABLE.)

AND … I just answered one of my own questions: Because it’s SCSI and SATA, S.M.A.R.T. is NOT supported … please make this a strong request for new features! (Thanks.)

My other question: why is the filesystem NOT clean on the last disk when re-booting in a short amount of time ? (SMART status is turned on on both IDE disks.)

Thanks for any hints or explanations.
Georg

S.M.A.R.T aka Self Monitoring Analysis and Reporting Technology is supported on SCSI - and was available on SCSI drives before it was available on the ATA/IDE drives.

S.M.A.R.T was derived from IBM's PFA or Predictive Failure Analysis - which was used on the AS/400 systems - it is generally attributed to Compaq, who introduced it in the PC Server arena, but the Compaq S.M.A.R.T drives were in fact made by IBM.

Thanks, fordem ... unfortunately (see below -- quote from Ralph on Tue Jul 11, 2006 11:26 pm) ...
I am hoping ServerElements has a way to grab the SMART data anyways. At minimum I am interested in keeping an eye on drive temperatures.
Georg

Two comments -

The clip you posted appears to refer to SATA, not SCSI

and -

Whilst Ralph is the authority on what features his products support - to the best of my (albiet limited) knowledge SMART information is available on SCSI drives in linux.

In Linux, in order to access SMART on a drive, the associated driver needs to transparently pass SMART commands to and from the drive. That transparency has been in place for IDE and SCSI for a while (Not to be confused with RAID).

SATA support is relatively new, so SATA drivers may or may not implement that capability. SATA support is a bit more advanced on the 2.6 kernel since SATA support in 2.4 is a back-port, but general functionality between the two is comparable for all practical purposes.

I hope that helps.

Yes, Tony, that helps. Thanks. Hope I can soon monitor temps of the new SATA drive in the hot closet where the NASLite server lives (we live in the valley in California with the reported 100+ heat-related deaths).

fordem: minor clarification: the Seagate drive is of course not on a SCSI interface ... NASLite only identifies it (and seems to treat it) as if it were a SCSI interface (as opposed to IDE) ... notice that even the USB stick (Disk-3) is labelled as (SCSI-3-0-0-0) ... confusing, I know.

Tony: any idea about the unclean fielsystem after quick reboot ?

If the drives are in proximity with each other and the airflow in the case is consistent, then the temp of the SATA disk will be equivalent or slightly higher than the IDE drives. This is only an assumption and can be quite unpredictable if airflow inside the case is improperly routed or inconsistent.

We will keep a close watch on what changes with libata in the 2.4 kernel to hopefully get SATA SMART transparency resolved.

I’m not sure why the large drive rechecks the file system on reboot. Does it do the same consistently and also does it do the same after a complete shutdown?

Also note that in Linux: USB, FireWire, SCSI, SATA and Hardware RAID disks are all seen as SCSI devices. Only IDE disks are not.

To answer some of your questions from your initial post, The reason SMART and Filesystem Repair options have an “*” is because they are disabled. If SMART is not available on the drive, then the associated option will be disabled. Similarly, if a disk is mounted and available for remote access, then it has passed the filesystem check at boot. The filesystem check option is therefore disabled. If a disk is not mounted due to an idle setting or a failed filesystem check at boot, then the option will be available.

Thanks ( again )

To each of your points:

1] proximity/airflow: yes that makes sense, and I thought of that too. On a brand-new drive monitoring its neighbor seems a reasonable method. *BUT* (the reason I have a new 500GB drive): the 2 year old 160GB Maxtor I had just put in there recently under v1.5 .... (sorry for being long-winded, but this experience may help someone else) well, under NASLite v2 it shows some more interesting SMART info than v1.5 ( I saw how you explained why in another post ), in particular a log of the last 5 or 6 prior errors. So I decided to run a full test -- it failed. When I shutdown and removed the drive it was immediately apparent that the Maxtor was running very hot (hard to tell from touch ... but maybe 10 or probably more degrees hotter than the others). I ran a Maxtor (MAXBLAST) short test; it recommeded to run the long test. The long test failed with the comment "diagnostic code de9e9d75. This drive is failing and must be replaced"

2] Monitoring "libata" (whatever that is -- I shall remain blissfully ignorant) ... yes, please do so ... and thanks for that.

3] It is *NOT* the LARGE drive each time that was unclean. That's the strange part. It seemed to be the LAST one in the drive sequence previously known (my original post might be a little obtuse in explaining that). Only quick reboots show the symptom. Reboots (or shutdowns with later startups) that are initiated after "longer" periods are ok. The time frames for the terms "quick" and "longer" are not well known -- but certainly everything I was doing (in my original post) was a "quick" (a few minutes) reboot time frame. What I did not mention in my original post: my status update interval is five minutes.

Not sure if this additional info will help any diagnosis, but there may be a consistency here in symptoms pointing to a bug in the code.

4] And thanks for your last paragraph ... good info. If that's not yet in the manual ... may I suggest putting it in there ?

Georg