[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15299: [PATCH 1/9] parted: fix EOF and ctrl-c handling

From: Phillip Susi
Subject: bug#15299: [PATCH 1/9] parted: fix EOF and ctrl-c handling
Date: Fri, 13 Sep 2013 16:44:44 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

Hash: SHA1

On 9/13/2013 3:19 PM, Brian C. Lane wrote:
> Why wouldn't the OS be able to see the full disk size? With a
> msdos label, yes, that is possible, but with GPT we cover the whole
> disk. There shouldn't be problems with the OS not being able to
> address the whole thing.

Say, some other OS's disk driver is limited to 32 bit addressing.

> This would also mean that we support violating the GPT spec, which
> says (in part) in seciton 5.3

I think it is quite a stretch to call "This is non standard, proceed
anyway?" "supporting" violating the standard.  I have always
subscribed to the philosophy of "be conservative in what you send, and
liberal in what you accept".  A warning is good, but a hard refusal to
accept something just because it violates a standard is a disservice
to the user.  Not having the backup at the end of the disk isn't very
likely to cause a problem, so if they think they have a good reason to
let it be, we should respect their wishes.

Note that script mode will take the safer option of bailing out, thus
proceeding is an explicit override from the user.

> I'm ok with fixing the backup location and the size as a single 
> warning/operation. But if they choose to leave it alone I think we 
> should refuse to make any changes to the disk. Anything else
> encourages the use of disks with things in the wrong place.

We don't have a mechanism to go read only; it is either bail out
completely or allow it to be ignored.  I don't like disabling the
ignore option unless the results are certain or very likely to be

>> I don't think that is enough.  Flushing the disk device will
>> clear out any stale data in that cache and force it to be re-read
>> from disk when we probe the fs type, but if the partition cache
>> still has dirty write buffers, the disk is still out of date so
>> re-reading it will still return stale data.
> Reading the partition nodes will still be stale, but we never do
> that so I don't think it is our job to handle that.

No, it is the reverse: the partition node has the updated data because
that is where mkfs wrote it.  It is the disk node that will return
stale data, even after it has been flushed, if the partition node
still has unflushed dirty data.

Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


reply via email to

[Prev in Thread] Current Thread [Next in Thread]