Re: legacy ticket: bad blocks.

[Curtis Gedak]

Hi Rod,

rod wrote:
> Has anyone considered the bad blocks problem that triggered my initial 
> question 
> (http://parted.alioth.debian.org/cgi-bin/trac.cgi/ticket/206#preview .)?
>   

I personally have not investigated this.  I am very busy working on GParted.

> For example, in FAT systems, there is a tagging mechanism for bad blocks in 
> the FAT (i.e. a partition-based address), to avoid writing data there.
>
> However, after a partition is moved or resized, that partition-based 
> bad-block address points to a different part of the physical disk.
>
> How can the mover/resizer avoid writing good data in that bad area?  It 
> would improve GParted's integrity if that could be done.
>   

Do you have good reference documentation that you are using that 
describe exactly how these bad sectors are marked in the FAT structure?

Is the marking scheme relative to the start of the partition, or is it 
the absolute sector number on the disk?

> Fortunately, modern disks have block or sector sparing mechanisms in the 
> firmware in addition to the file system bad block mechanisms; I believe one 
> system provides a couple of spare sectors to relocate bad blocks from the 
> same track.
>
> So there has to be an accumulation of physical errors that exceed the 
> firmware's capability, before the filesystem starts to see bad blocks. With 
> my assortment of well-used disks it seems to take a few years before the 
> number of filesystem-based bad blocks becomes significant.  But with older 
> disks, moving/resizing partitions becomes risky, unless there's provision 
> for bad blocks.
>
> Have I understood the situation? -- Please put me right if I've got it 
> wrong.  Thanks.
>   

I think you have a good understanding, probably better than me, of the 
situation.  The following article on the FAT32 file system seems to 
agree that with modern disk drives handling of bad sectors, these should 
never become visible to the IDE interface and hence the FAT file system.

Understanding FAT32 File Systems
http://www.pjrc.com/tech/8051/ide/fat32.html

Regards,
Curtis Gedak