On Nov 4, 2013, at 3:09 PM, Jeffrey Bastian wrote:
> On Thu, Oct 24, 2013 at 12:46:17PM -0600, Chris Murphy wrote:
>> On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian wrote:
>>> I have a system that corrupts the backup GPT on every reboot.
>>
>> Certain RAID implementations write metadata at the e
On Thu, Oct 24, 2013 at 12:46:17PM -0600, Chris Murphy wrote:
> On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian wrote:
> > I have a system that corrupts the backup GPT on every reboot.
>
> Certain RAID implementations write metadata at the end of the disk and
> step on the backup GPT in this manner.
On Oct 24, 2013, at 11:51 AM, Miloslav Trmač wrote:
>
> Please let's not mix the two concepts of "tools" quoted above.
>
> If the proposal is to run something by default on every bootup, it
> must be overwhelmingly safe, not apply heuristics that may break the
> system even more.
Right. If any
On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian wrote:
> On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
>> The bottom line question is, would it be useful to have an fsck_gpt
>> run by systemd at either startup or shutdown time?
>
> I have a system that corrupts the backup GPT on e
On Oct 24, 2013, at 8:59 AM, John Reiser wrote:
>
> Such a tool also should diagnose both overlap and unclaimed space,
> and provide some means for repair of these conditions.
> For example in the case of "minor" overlap: repair might be "minimum wins",
> "maximum wins", or arbitrary edit of ext
On Oct 24, 2013, at 2:33 AM, Richard W.M. Jones wrote:
> On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
>> So that's why I ask if it makes sense to have an fsck for GPT disks.
>
> Sounds sensible. The "fsck" would just check the checksums of primary
> & secondary tables, and if
On Thu, Oct 24, 2013 at 4:59 PM, John Reiser wrote:
> On 10/24/2013 01:33 AM, Richard W.M. Jones wrote:
>> On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
>>> So that's why I ask if it makes sense to have an fsck for GPT disks.
>>
>> Sounds sensible. The "fsck" would just check the
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
> The bottom line question is, would it be useful to have an fsck_gpt
> run by systemd at either startup or shutdown time?
I have a system that corrupts the backup GPT on every reboot: the CRC32
in the backup GPT is always 0. I run pa
On 10/24/2013 01:33 AM, Richard W.M. Jones wrote:
> On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
>> So that's why I ask if it makes sense to have an fsck for GPT disks.
>
> Sounds sensible. The "fsck" would just check the checksums of primary
> & secondary tables, and if an error
On Wed, Oct 23, 2013 at 10:49:35PM -0600, Chris Murphy wrote:
> So that's why I ask if it makes sense to have an fsck for GPT disks.
Sounds sensible. The "fsck" would just check the checksums of primary
& secondary tables, and if an error in either (but not both) is
detected it would restore from
The bottom line question is, would it be useful to have an fsck_gpt run by
systemd at either startup or shutdown time? This wasn't needed for MBR, so it
seems kinda silly to suggest it, but there are some cases of one or the other
GPT being stepped on in a way that probably never happened to MB
11 matches
Mail list logo
