Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Yesterday evening I started seeing some disk errors on the home partition, /dev/sda2, of my Fedora 17 box. Here is a line from dmesg:
Code:
[2300766.067364] EXT4-fs error (device sda2): ext4_wait_block_bitmap:447: comm flush-8:0: Cannot read block bitmap - block_group = 121, block_bitmap = 3670025
[2300775.140555] EXT4-fs (sda2): delayed block allocation failed for inode 2230055 at logical offset 65 with max blocks 2 with error -5
[2300775.140560] EXT4-fs (sda2): This should not happen!! Data will be lost
I see this error for three different inodes.
Right now, I am in the process of copying a collection of MP3s to a USB drive but for some reason it is going extremely slowly (approx. 1G/hour). What I would really like to do is boot from Fedora in rescue mode from a USB stick, mount the problematic partition, and copy the remaining MP3s to the USB drive, but I am apprehensive that the partition won't be mountable if the disk is corrupted in any way.
The best strategy would be to make an image from that partition using ddrescue (or the whole disk, if necessary) and try to retrieve your data from that image.
Depending on the cause, the type and severity of errors seen and if data is "just" hard to come by or irreplaceable running fsck may (or may not) be a critical error of judgment. Running fsck in the face of hardware trouble may even compound the problem and thwart later recovery attempts.
Quote:
Originally Posted by TobiSGD
The best strategy would be to make an image from that partition using ddrescue (or the whole disk, if necessary) and try to retrieve your data from that image.
That doesn't really address the OP being apprehensive wrt disk corruption, doesn't it? Or would you be able to put your hand on your heart and say the block access failures shown represent isolated incidents? Or phrased differently, what diagnostics would make you decide to stop copying and start a dd_rescue / ddrescue? Just being curious because I have had copy ops stop and then start a dd only to find the disk wouldn't power up again...
That doesn't really address the OP being apprehensive wrt disk corruption, doesn't it? Or would you be able to put your hand on your heart and say the block access failures shown represent isolated incidents? Or phrased differently, what diagnostics would make you decide to stop copying and start a dd_rescue / ddrescue? Just being curious because I have had copy ops stop and then start a dd only to find the disk wouldn't power up again...
You are right, I didn't realize that the OP is still copying at this state. It comes down to calculate the risks: Is it more risky to stop the copying process and make an image or is it more risky to let the drive trying to copy the MP3s and maybe die in that process due to the stress on that? Copying with ddrescue will continue the progress with another sector, leaving the bad sector for later rescue attempts, so that at least the known good sectors are copied. Copying with ordinary copy commands will try to read the same sector over and over again, regardless if it is able to recover that sector or not, putting more stress on the disk, I would think. In this case i would go so far and unm,ount the /home partition to make an image of it, no need for live-CDs or power-downs. Of course only viable if the OP has an external medium large enough to hold the image.
I think the best option is to use dd_rescue, and if possible, make the target a sparse file so as to save space.
Most important think it so avoid powering the disk down and back up, as any time it goes down, might be the last time.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.