From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: Justin Piszcz <jpiszcz@lucidpixels.com>, xfs@oss.sgi.com
Subject: Re: zero size file after power failure with kernel 2.6.30.5
Date: Sun, 30 Aug 2009 10:39:04 +0200 [thread overview]
Message-ID: <200908301039.05303@zmi.at> (raw)
In-Reply-To: <alpine.DEB.2.00.0908291517350.24777@p34.internal.lan>
On Samstag 29 August 2009 Justin Piszcz wrote:
> I was curious if you could show your smartctl -a output?
>
> smartctl -a /dev/sda
Here the important parts of it:
Device Model: WDC WD1500HLFS-01G6U0
Firmware Version: 04.04V01
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0003 190 185 021 Pre-fail Always - 1466
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 48
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x000e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 6282
10 Spin_Retry_Count 0x0012 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0012 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 48
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 13
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 48
194 Temperature_Celsius 0x0022 112 102 000 Old_age Always - 31
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0010 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
PNum Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 6274 -
# 2 Extended offline Completed without error 00% 6251 -
# 3 Short offline Completed without error 00% 6250 -
# 4 Short offline Completed without error 00% 6226 -
# 5 Short offline Completed without error 00% 6202 -
# 6 Short offline Completed without error 00% 6187 -
# 7 Extended offline Completed without error 00% 6167 -
# 8 Short offline Completed without error 00% 6145 -
# 9 Short offline Completed without error 00% 6121 -
#10 Short offline Completed without error 00% 6097 -
#11 Extended offline Completed without error 00% 6090 -
#12 Extended offline Completed without error 00% 6024 -
#13 Short offline Completed without error 00% 3613 -
#14 Short offline Completed without error 00% 3589 -
#15 Extended offline Completed without error 00% 3567 -
#16 Short offline Completed without error 00% 3565 -
#17 Short offline Completed without error 00% 3541 -
#18 Short offline Completed without error 00% 3517 -
#19 Short offline Completed without error 00% 3493 -
#20 Short offline Completed without error 00% 3469 -
#21 Short offline Completed without error 00% 3445 -
> The SU issue most likely resulted in the xfs file going to 0 issue
> (i see the same thing on occasion during a PSU issue or crash/reboot)
Yes, and that's annoying. I've never had that for reiserfs, so I guess it's really XFS
to blame here. I like that filesystem, but such things really shouldn't happen.
> however I am curious to see if you see any of the issues here:
> http://forums.storagereview.net/index.php?showtopic=27303&hl=velociraptor
>
> Since you only use one drive and not a raid of the WD Velociraptors,
> you may not be affected, but I was curious, thanks.
In fact I use 3 VelociRaptor 150GB and 6 Raptors. 8 are in a single RAID-6
in a server running since about 3 years, and during this time 2 Raptors
died and were replaced by VelociRaptors. The one I use in my desktop
is a spare spart to use in case the server needs one. I just use it because
the speed is nice, and I see if it has failures.
Smartctl is running as a daemon here, so you can see the SMART self
tests. It's almost definitely not the drive.
mfg zmi
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660 / 415 65 31 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-08-30 8:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-29 19:02 zero size file after power failure with kernel 2.6.30.5 Michael Monnerie
2009-08-29 22:13 ` Eric Sandeen
2009-08-31 23:10 ` Peter Grandi
2009-09-01 7:18 ` Michael Monnerie
2009-09-01 10:32 ` Peter Grandi
2009-09-01 14:19 ` Emmanuel Florac
2009-09-01 22:52 ` Michael Monnerie
[not found] ` <alpine.DEB.2.00.0908291517350.24777@p34.internal.lan>
2009-08-30 8:39 ` Michael Monnerie [this message]
2009-09-18 20:05 ` Martin Steigerwald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200908301039.05303@zmi.at \
--to=michael.monnerie@is.it-management.at \
--cc=jpiszcz@lucidpixels.com \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox