[parted-devel] Logical sector size warning still accurate?

[Jim Meyering]

Colin Watson wrote:
> On Fri, Feb 26, 2010 at 04:06:16PM +0100, Jim Meyering wrote:
>> Colin Watson wrote:
>> > libparted still includes this warning:
>> >
>> >         if (dev->sector_size != PED_SECTOR_SIZE_DEFAULT) {
>> >                 ped_exception_throw (
>> >                         PED_EXCEPTION_WARNING,
>> >                         PED_EXCEPTION_OK,
>> >                         _("Device %s has a logical sector size of %lld.  Not "
>> >                           "all parts of GNU Parted support this at the moment, "
>> >                           "and the working code is HIGHLY EXPERIMENTAL.\n"),
>> >                         dev->path, dev->sector_size);
>> >         }
>> >
>> > Is this still accurate?  Given that we've now had a stable release
>> > advertising support in its NEWS file for >512-byte sectors, it seems odd
>> > that libparted still throws an exception when it encounters such disks.
>>
>> That warning is still apt for some use cases.
>> Is it causing trouble?
>>
>> If you limit your usage to GPT and MSDOS partition tables and
>> don't use any of parted's file system-related operations,
>> you may be safe.  But until such disks come into regular use,
>> it's probably still warranted.
>
> I guess I'm mostly worried about shipping an OS that will issue a scary
> warning on disks that are likely to come into regular use well within
> its support lifetime, and I wanted to know whether folks had simply
> forgotten to remove the warning (since this does happen sometimes).

Considering that anyone still using FS-oriented operators now gets
the new deprecation warnings, it should be alright to remove the
above warning.  I've just pushed the patch included below.

>> For example, I don't have such a disk (though could probably arrange
>> for intermittent, inconvenient remote access, if I tried).  Find a
>> donor and that code will surely get a lot more testing than it does now.
>
> I have such a disk now, although am having some tangential hardware
> trouble getting it set up (the problem with working from home is that
> you have to do all your own hardware maintenance ...); I will be testing
> parted 2.2 with it in the context of Ubuntu.  I don't know if I have any
> relevant good offices, but I can certainly ask the same donor if they
> have any more to spare.

That would be nice.

> In the meantime, do you have a hit-list of things you'd like me to test
> and fix as necessary?

Thanks for asking.

At the top of my to-do-for-parted list is to "remove FS-op support"
(i.e., anything that performs FS-aware tasks from parted).
However, that is complicated by the need to retain support
for HFS- and FAT resizing, since there appear to be no free replacement
tools that can do that.  If you know of such tools, please tell us
so Parted clients like GParted can start to use them -- and so
I can remove even more of the FS-related (bit-rotting) code here
in parted.
--------------------------------

Currently, tests of a few odd-ball partition types are disabled
because they were failing with simulated >512-byte sectors, yet
not deemed important enough to invest in fixing.

Here's the list:

  amiga, bsd, aix, pc98

That just means if you try to put such a partition table on a disk with
>512-byte sectors and then tell parted to do something with it, parted
will probably corrupt heap and/or stack and generally misbehave.

If you know of anyone who cares about those partition table types
(on >512-byte sector disks) and knows how they should be laid out
on such disks, please give details.

Actually, I've just removed "bsd" from the exception list (in
libparted/tests/common.c) and confirmed that all of the
"make check" tests still pass.  So that leaves only 3.
Removing any of the other three induces test failures.
--------------------------------

Another task would be to run "make coverage" and see what
sort of test coverage "make check" provides.  Then, of course,
start adding tests to exercise the parts that looks most important
but that have no coverage.