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: r...@rodericksmith.plus.com Web: http://www.rodericksmith.plus.com -----Original Message----- From: Curtis Gedak [SMTP:ged...@gmail.com] Sent: Thursday, August 19, 2010 6:55 PM To: r...@rodericksmith.plus.com Cc: Jim Meyering; 'bug-parted@gnu.org' 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/parted-de...@lists.alioth.debian.org/msg0272 8.html Regards, Curtis Gedak (Maintainer of GParted) _______________________________________________ bug-parted mailing list bug-parted@gnu.org http://lists.gnu.org/mailman/listinfo/bug-parted
