On Thu, Oct 24, 2013 at 12:46:17PM -0600, Chris Murphy wrote:
On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian jbast...@redhat.com 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
On Nov 4, 2013, at 3:09 PM, Jeffrey Bastian jbast...@redhat.com wrote:
On Thu, Oct 24, 2013 at 12:46:17PM -0600, Chris Murphy wrote:
On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian jbast...@redhat.com wrote:
I have a system that corrupts the backup GPT on every reboot.
Certain RAID
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
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 in
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
On Thu, Oct 24, 2013 at 4:59 PM, John Reiser jrei...@bitwagon.com 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
On Oct 24, 2013, at 2:33 AM, Richard W.M. Jones rjo...@redhat.com 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
On Oct 24, 2013, at 8:59 AM, John Reiser jrei...@bitwagon.com 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
On Oct 24, 2013, at 9:40 AM, Jeffrey Bastian jbast...@redhat.com 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
On Oct 24, 2013, at 11:51 AM, Miloslav Trmač m...@volny.cz 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.
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
11 matches
Mail list logo
