RE: legacy ticket: bad blocks.

[rod]

Hi, Curtis

Thanks for that -- its reassuring that resize/move will still be available 
for FAT and linux partitions.

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

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.

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.

Regards from

Rod Smith

Mailto: address@hidden
Web:   http://www.rodericksmith.plus.com



-----Original Message-----
From:   Curtis Gedak [SMTP:address@hidden
Sent:   Thursday, August 19, 2010 6:55 PM
To:     address@hidden
Cc:     Jim Meyering; 'address@hidden'
Subject:        Re: legacy ticket: bad blocks.

Jim Meyering wrote:
> rod wrote:
>
>> What's the thinking behind phasing out filesystem-dependent operations?
>>  Perhaps the functionality is being moved to individual libraries 
supported
>> elsewhere?  Will the ability to move and resize file systems be phased 
out
>> of libparted as well as out of  parted? (I guessed this might also be 
the
>> forum for libparted, but may be wrong.)
>>
>
> It's been discussed at length on this list and/or on parted-devel.
> Here's an example, with explanation that updates README:
>
>   http://thread.gmane.org/gmane.comp.gnu.parted.devel/2994
>
>
>> I use gparted for resizing partitions; that calls libparted directly, 
and
>> makes some use of other tools.
>>
>
> If you stick to using gparted, I am confident that
> you will see no change in available functionality.
>

Hi Rod,

Jim is correct.  The GParted project will endeavour to maintain both
partition editing and file system  resizing support.  Hence you should
not see a loss in available functionality in GParted.

Jim has offered to keep the FAT16/32 and HFS/+ file system resizing code
available in the libparted library until there is another free open
source software tool that is willing to take over this code.  Hence
projects like GParted, which use the libparted library, will still have
access to this code.  Of course the file system resizing code may
require some patches to keep it up to date so please do feel free to
examine this library and contribute to the Parted project.

As Jim mentioned, this topic has been discussed previously in the parted
mailing list.  One such thread can be found at the following link:
http://www.mail-archive.com/address@hidden/msg0272  
8.html

Regards,
Curtis Gedak
(Maintainer of GParted)