bug-parted
[Top][All Lists]
Advanced

[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

-----BEGIN PGP SIGNED MESSAGE-----
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
catastrophic.

>> 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.


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

iQEcBAEBAgAGBQJSM3k8AAoJEJrBOlT6nu756v4IAL/C2FXzSJmjH3P8LtJph7a4
6y1z4TMcd9z8MuF2qrV/454ZR8to6wwSJ8+L/Q+8OpJd/5y/jXsUCjEGPglG7vYF
2ms8g8VQoq3Ds1f6kT8wxrf3FHkeo42gaMGhTHWJl4e2L10LMkXxLLzsWE3dwqbP
nc2gE2HpVzrJX7rKoup+2W0KLWV5UfWAvekmk8do7VapoDrmNQyr0Pdetu83gkhx
q6VPQazkE5vibPRinRwRlEt7b2nnALVkIDUjZKO4oBA4S2umdgH9NCQrjXzHVb08
UzP/eAijrlCYvuSHkkqBQwa3cKEe9EnDP2FfUrE1aoevAHlnCDeoxcVSNF79yWM=
=mxwB
-----END PGP SIGNATURE-----





reply via email to

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