Content-Type: multipart/alternative; boundary="------------000000000007030401010909" --------------000000000007030401010909 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Adam, can you, please, help me finding the correct entry for "Partition start offset byte"? The secinspect output is attached. Partition 1 is boot partition Partition 2 is system partition Partition 3 is data partition Thank you very much. Regards Bernd > -------- Original Nachricht/Message --------- > Betreff/Subject: *Re: [smartmontools-support] How to deal with defect > block* > Datum/Date: *Montag, 21. Juli 2014 15:16:52* > > > > Hi, > > Please find attached an OpenDocument spreadsheet to help with this. If > you find a better way of finding the file - instead of manually like > this - please let me know! > > You will need to find out the partition offset. One method is using > Microsoft's free secinspect.exe > Find the correct physical drive from the output, and then look for the > StartingLBA number listed under the table for the Partition Table > Entry. This is the "partition start offset byte" for the spreadsheet. > The data here is a bit confusing but if you read through it carefully > you should get an idea of which partitions are system ones and which > has your data on it. > > Your disk may have a sector size of 512 or 4096 bytes, this should > also be listed in secinspect's output as "BytesPerSector". For "file > system block size" this is usually 4096 bytes by default for NTFS, but > must be verified. chkdsk > > On the spreadsheet, "Bad LBA start" and "Number of bad LBAs" are where > you enter data about the faulty sector and how many there are > (sometimes disks have a block of them), you'll be then given the first > and last file system block. Look for this using Sysinternals' free > DiskView program. This requires some time and patience as you have to > zoom in and out and use trial and error to find the correct file. > > This entire method is laborious and has to be followed carefully, but > in my experience it has proven accurate. It has also, in every time > I've used it, found that some useless file is affected :-D --------------000000000007030401010909 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Adam,
can you, please, help me finding the correct entry for "Partition start offset byte"?
The secinspect output is attached.
Partition 1 is boot partition
Partition 2 is system partition
Partition 3 is data partition
Thank you very much.
Regards
Bernd

-------- Original Nachricht/Message ---------
Betreff/Subject: Re: [smartmontools-support] How to deal with defect block
Datum/Date: Montag, 21. Juli 2014 15:16:52



Hi,

Please find attached an OpenDocument spreadsheet to help with this. If you find a better way of finding the file - instead of manually like this - please let me know!

You will need to find out the partition offset. One method is using Microsoft's free secinspect.exe
Find the correct physical drive from the output, and then look for the StartingLBA number listed under the table for the Partition Table Entry. This is the "partition start offset byte" for the spreadsheet. The data here is a bit confusing but if you read through it carefully you should get an idea of which partitions are system ones and which has your data on it.

Your disk may have a sector size of 512 or 4096 bytes, this should also be listed in secinspect's output as "BytesPerSector". For "file system block size" this is usually 4096 bytes by default for NTFS, but must be verified. chkdsk

On the spreadsheet, "Bad LBA start" and "Number of bad LBAs" are where you enter data about the faulty sector and how many there are (sometimes disks have a block of them), you'll be then given the first and last file system block. Look for this using Sysinternals' free DiskView program. This requires some time and patience as you have to zoom in and out and use trial and error to find the correct file.

This entire method is laborious and has to be followed carefully, but in my experience it has proven accurate. It has also, in every time I've used it, found that some useless file is affected :-D

--------------000000000007030401010909--