[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: legacy ticket: bad blocks.
From: |
rod |
Subject: |
RE: legacy ticket: bad blocks. |
Date: |
Thu, 19 Aug 2010 20:58:16 +0100 |
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)