From: Ronan CHAUVIN <ronan.chauvin@parrot.com>
To: "Dale R. Worley" <worley@alum.mit.edu>
Cc: <util-linux@vger.kernel.org>,
matthieu CASTET <matthieu.castet@parrot.com>,
Alexandre Dilly <alexandre.dilly@parrot.com>
Subject: Re: [libfdisk]: gpt_write_disklabel function robustness to sudden power off
Date: Tue, 24 Mar 2015 14:54:49 +0100 [thread overview]
Message-ID: <55116CA9.3040402@parrot.com> (raw)
In-Reply-To: <87384vyt4y.fsf@hobgoblin.ariadne.com>
Thank you for your answer.
If we are not resizing/adding but just renaming a partition, we want to
be sure that at least the primary or the backup GPT header/GPT partition
array will not be corrupted in the case of a sudden power-off. If the
write order is not guaranty, then the primary and backup GPT headers can
be written to the emmc without the corresponding partition array and the
system will not be consistent.
For example, if we have this effective write operation order on the disk:
1) backup GPT header
2) primary GPT header
--> power-off <--
3) primary partition tables
4) backup partition tables
5) protective MBR
then, CRC of partition array present in both GPT headers will be incorrect.
On 03/24/2015 04:24 AM, Dale R. Worley wrote:
> But it seems to me that there is
> no such consistent state -- what condition would you want that
> information to be in? The old information is irretrevably lost during
> the operation;
--
Ronan CHAUVIN
Embedded Software Engineer
ASIC team
--------------------------------
Parrot
174, quai de Jemmapes
75010 Paris France
--------------------------------
www.parrot.com
prev parent reply other threads:[~2015-03-24 13:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-20 10:17 [libfdisk]: gpt_write_disklabel function robustness to sudden power off Ronan CHAUVIN
2015-03-20 11:18 ` Karel Zak
2015-03-23 18:31 ` Peter Cordes
2015-03-24 14:05 ` Ronan CHAUVIN
2015-03-24 14:25 ` Peter Cordes
2015-03-26 13:07 ` Ronan CHAUVIN
2015-03-24 3:24 ` Dale R. Worley
2015-03-24 13:54 ` Ronan CHAUVIN [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55116CA9.3040402@parrot.com \
--to=ronan.chauvin@parrot.com \
--cc=alexandre.dilly@parrot.com \
--cc=matthieu.castet@parrot.com \
--cc=util-linux@vger.kernel.org \
--cc=worley@alum.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.