[Nottingham] kernel 2.6.27: INFO: task xxxx blocked for more than 120 seconds.

[Jim Moore]

Michael Erskine wrote:
>> I'm using "tar c | tar d" to compare 200 GBytes of data between a
>> firewire external HDD and a USB2 externel HDD, both using reiserfs.
>>     
>
> In the absence of evidence, I put the blame on Reiserfs because it
> acts like it has something to hide ;)
>
> Regards,
> Michael.
>
> _______________________________________________
> Nottingham mailing list
> Nottingham at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/nottingham
>
>   
Right root cause as far as I can make out; it's down to the fact, 
Martin, that you're using a journaling file system on external drives - 
never a good idea (try it with NTFS5 sometime!). Recovering data from a 
corrupted NTFS or ReiserFS or ext3 external drive is frankly, a pain in 
the posterior (been there, worn the shirt, never again!) because the 
last thing the drive does before parking the head is flush the cache to 
the platters and finalise the inode tables to reflect the current state 
of the drive*. If there's a power failure or fluctuation this cache is 
flushed and the data is permanently lost (and the drive falls back to 
the last complete copy of the inode table), the actual data on the drive 
marked as dirty and unusable and overwritten at some point. Recovery at 
that point is time consuming and expensive and involves deep scanning 
which could physically destroy the drive.

*unlike FAT/ext2 and other basic filesystems where the data stream 
bypasses the cache and the inode tables are updated on the drive itself 
as the data is being written. OK this is slower than a JFS and only uses 
one MFT but that MFT is always regarded as complete.

HTH,

TLP