Jump to content

One hard drive can't be filled


Jomp

Recommended Posts

One of my drives can't be written past a certain point. It's a 2tb drive that I can't write beyond 68gb or so. I know it's not good to fill them up that much but I'm more curious about the why, since I can fill the rest of my drives much closer to the 2tb limit. It's just this one hard drive that won't fill up.

 

It passed a fscheck and a long SMART test.

 

This happens during any type of data copy like an OSX smb copy, cp from other unraid drives, etc. The copy will stall at the same point, with the webgui showing lots of reads before the copy eventually fails. Any ideas?

Link to comment

One of my drives can't be written past a certain point. It's a 2tb drive that I can't write beyond 68gb or so. I know it's not good to fill them up that much but I'm more curious about the why, since I can fill the rest of my drives much closer to the 2tb limit. It's just this one hard drive that won't fill up.

 

It passed a fscheck and a long SMART test.

 

This happens during any type of data copy like an OSX smb copy, cp from other unraid drives, etc. The copy will stall at the same point, with the webgui showing lots of reads before the copy eventually fails. Any ideas?

Since you did not post anything to use for analysis, all we can offer is a general answer.

 

That drive has something different/odd/wrong with it.

 

If you can only write to 68Gig of a 2000 Gig drive, I'd say something might be wrong.

 

Post the output of the smartctl report.

Post a syslog captured after the write to the drive fails, but before you reboot.

Post the output of a hdparm -N /dev/sdX command.

Post the output of a hdparm -i

 

A "long" smart test simply attempts to read all the disks sectors.  It does not write to the disk.  You are complaining about "writing", so the "long" test might not indicate anything regarding your failure to write.

 

Joe L.

 

 

Link to comment

That drive has something different/odd/wrong with it.

 

If you can only write to 68Gig of a 2000 Gig drive, I'd say something might be wrong.

 

Post the output of the smartctl report.

Post a syslog captured after the write to the drive fails, but before you reboot.

Post the output of a hdparm -N /dev/sdX command.

Post the output of a hdparm -i

 

A "long" smart test simply attempts to read all the disks sectors.  It does not write to the disk.  You are complaining about "writing", so the "long" test might not indicate anything regarding your failure to write.

 

Joe L.

 

I typed that incorrectly, my apologies. It should have said that I can't write to the LAST 68Gigs of a 2000Gig drive. That makes quite a bit of difference. I can fill all my other drives right up to the limit, but for whatever reason, this one can only fill to 97%.

Link to comment

 

Is this a common occurrence, not being able to fill a disk up completely? Is it something that others have experienced? I'll post the SMART and hdparm if they are still relevent. I'm not sure they still are, since I essentially wrote my problem backwards.  :D

Link to comment

That drive has something different/odd/wrong with it.

 

If you can only write to 68Gig of a 2000 Gig drive, I'd say something might be wrong.

 

Post the output of the smartctl report.

Post a syslog captured after the write to the drive fails, but before you reboot.

Post the output of a hdparm -N /dev/sdX command.

Post the output of a hdparm -i

 

A "long" smart test simply attempts to read all the disks sectors.  It does not write to the disk.  You are complaining about "writing", so the "long" test might not indicate anything regarding your failure to write.

 

Joe L.

 

I typed that incorrectly, my apologies. It should have said that I can't write to the LAST 68Gigs of a 2000Gig drive. That makes quite a bit of difference. I can fill all my other drives right up to the limit, but for whatever reason, this one can only fill to 97%.

Regardless of the size you are unable to write to, we still need the same outputs from the same commands I listed earlier in order to diagnose what is happening.    (glad it is only the last 68Gig.)  No, it is not a normal occurrence.

 

Joe L.

Link to comment

SMART:

 

 

SMART Attributes Data Structure revision number: 10

Vendor Specific SMART Attributes with Thresholds:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE

 1 Raw_Read_Error_Rate     0x000f   113   100   006    Pre-fail  Always       -       52415474

 3 Spin_Up_Time            0x0003   100   100   000    Pre-fail  Always       -       0

 4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       291

 5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0

 7 Seek_Error_Rate         0x000f   067   060   030    Pre-fail  Always       -       6050107

 9 Power_On_Hours          0x0032   094   094   000    Old_age   Always       -       5432

10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0

12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       72

183 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0

184 Unknown_Attribute       0x0032   100   100   099    Old_age   Always       -       0

187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0

188 Unknown_Attribute       0x0032   100   100   000    Old_age   Always       -       0

189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0

190 Airflow_Temperature_Cel 0x0022   071   066   045    Old_age   Always       -       29 (Lifetime Min/Max 25/34)

194 Temperature_Celsius     0x0022   029   040   000    Old_age   Always       -       29 (0 13 0 0)

195 Hardware_ECC_Recovered  0x001a   051   035   000    Old_age   Always       -       52415474

197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0

198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0

199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       198491913586650

241 Unknown_Attribute       0x0000   100   253   000    Old_age   Offline      -       3706874541

242 Unknown_Attribute       0x0000   100   253   000    Old_age   Offline      -       2381941921

 

Hdparm:

 

 

root@Media:~# hdparm -i /dev/sde

 

/dev/sde:

 

Model=ST32000542AS                            , FwRev=CC35    , SerialNo=            6XW0GPDT

Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }

RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4

BuffType=unknown, BuffSize=0kB, MaxMultSect=16, MultSect=?16?

CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=18446744073321613488

IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}

PIO modes:  pio0 pio1 pio2 pio3 pio4

DMA modes:  mdma0 mdma1 mdma2

UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6

AdvancedPM=yes: unknown setting WriteCache=enabled

Drive conforms to: unknown:  ATA/ATAPI-4,5,6,7

 

* signifies the current active mode

 

root@Media:~# hdparm -N /dev/sde

 

/dev/sde:

max sectors   = 18446744073321613488/14715056, HPA setting seems invalid

 

 

Nothing shows up in the syslog about it at all..

Link to comment

That drive has something different/odd/wrong with it.

 

If you can only write to 68Gig of a 2000 Gig drive, I'd say something might be wrong.

 

Post the output of the smartctl report.

Post a syslog captured after the write to the drive fails, but before you reboot.

Post the output of a hdparm -N /dev/sdX command.

Post the output of a hdparm -i

 

A "long" smart test simply attempts to read all the disks sectors.  It does not write to the disk.  You are complaining about "writing", so the "long" test might not indicate anything regarding your failure to write.

 

Joe L.

 

I typed that incorrectly, my apologies. It should have said that I can't write to the LAST 68Gigs of a 2000Gig drive. That makes quite a bit of difference. I can fill all my other drives right up to the limit, but for whatever reason, this one can only fill to 97%.

Regardless of the size you are unable to write to, we still need the same outputs from the same commands I listed earlier in order to diagnose what is happening.    (glad it is only the last 68Gig.)  No, it is not a normal occurrence.

 

Joe L.

 

As the transfer stalls, the webgui will show read after read on the drive and top shows the free memory slowing being eaten up until it gets very low and then the transfer will fail. After all this, unraid won't flag a write error and nothing shows up in the syslog.

 

*EDIT: On a different 2000GB disk that has 20GB free, I just tried to transfer a 8GB file. It fails to start the first time, just shows a few thousand reads on the webgui. After trying to transfer the file a second time, it starts and finishes. Could this be an OSX SMB implantation thing?

 

*EDIT 2: Weird. In trying to prove or disprove the OSX theory, I just fired up my virtualized Windows 7 install on the same machine. It paused for a while at the 68GB point that OSX always stalls on, but then moved on and completed the transfer. I then deleted that file and OSX can now write past the 68GB point. So strange.

Link to comment

Archived

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

×
×
  • Create New...