1

Possible Duplicate:
Kernel Errors Present: EXT4-fs

I resized a partition (using Gparted live cd), and it went fine. A day later I've started to get EXT errors. Could these two events be dependent, or most likely it's a hardware issue?

Errors from kernel.log

Feb  3 12:27:44 evgeny-dell kernel: [  308.088401] EXT4-fs (sda1): error count: 11

Feb  3 12:27:44 evgeny-dell kernel: [  308.088405] EXT4-fs (sda1): initial error at 1359831799: ext4_ext_search_left:1224: inode 309104
Feb  3 12:27:44 evgeny-dell kernel: [  308.088408] EXT4-fs (sda1): last error at 1359886942: ext4_remount:4539: inode 309104

Output of SMART:

SMART Attributes Data Structure revision number: 16

Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   187   187   021    Pre-fail  Always       -       1633
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       211
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       598
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       207
191 G-Sense_Error_Rate      0x0032   001   001   000    Old_age   Always       -       4257
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       45
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       1573
194 Temperature_Celsius     0x0022   104   099   000    Old_age   Always       -       43
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       0
240 Head_Flying_Hours       0x0032   100   100   000    Old_age   Always       -       579
241 Total_LBAs_Written      0x0032   200   200   000    Old_age   Always       -       620156852
242 Total_LBAs_Read         0x0032   200   200   000    Old_age   Always       -       607562502
254 Free_Fall_Sensor        0x0032   199   199   000    Old_age   Always       -       1

SMART Error Log Version: 1
No Errors Logged
Community
  • 1
J-unior
  • 149
  • 5
  • 1
    why don't you post the error messages you get? – Sven Feb 03 '13 at 12:36
  • Edited and added – J-unior Feb 03 '13 at 12:43
  • 2
    I've broken partitions before with GParted, so not unprecedented. Of course it could be normal drive attrition. Perhaps it is using a part of the disk not used before. With this type of activity, it's not as if there will be a GParted-specific error code. – Greg Askew Feb 03 '13 at 12:47
  • On the one hand the laptop is a few months old, on the other it's hardrive clicks once in a hour since the first time I've turned it on. The question is whether I should try to use my warranty, or rewrite the partitions... – J-unior Feb 03 '13 at 13:00
  • 1
    When you say you resized the partition, did you grow it or shrink it? Growing it shouldn't break the filesystem. Shrinking it is almost guaranteed to break the filesystem unless you shrank the filesystem before shrinking the partition. – Celada Feb 03 '13 at 14:05
  • Get it. I did shrink, it. Now when I recall how ext FS works (putting files at even distance to ensure there will be no need for defrag) I understand why it allways worked with NTFS and there is no chance it will work in EXT. Extract your comment to an answer please, so I could accept it. – J-unior Feb 03 '13 at 14:37
  • 1
    Gparted already resizes the filesystem for you. You would see this in the details of the operation. So it's not likely to be that. – Michael Hampton Feb 03 '13 at 17:01
  • This becoming more and more interesting :-) However I don't think Gparted was successful, because just a moment ago I've `resize2fs` and `fsck` passed fine, while it failed before. – J-unior Feb 03 '13 at 20:00

2 Answers2

2

Yes. That's why every even half decent partitioning tool warns you about it. Just restore from the backup you took before repartitioning. You know, that one you took in case this sort of thing happened.

John Gardeniers
  • 27,458
  • 12
  • 55
  • 109
1

If you know what you are doing then it is safe, it's an everyday thing to do. But you should always have backups!

In the deep level when you grow a filesystem-partiton then you to the following:

  1. Repartition the disks to make the partition containing your filesystem bigger. This doesn't touches your filesystems just the partition table.
  2. Grow your filesystem to the size of your new partition. In EXT resize2fs does this for you and it is safe. Also it forces you to do fsck before.

when you shrink a filesystem-partition then:

  1. You shrink the filesystem to fit the new size, again with resize2fs.
  2. Resize your partition. This is the tricky part because if you shrink it too mutch then you can cut your filesystem's end.

Tools like gparted automates the upper process.

But as always every program can have errors, but usually it is a safe process.

Stone
  • 7,011
  • 1
  • 21
  • 33