From: Mark Ballard Subject: Re: Corrupted superblock? But disk still mounts. Date: Fri, 22 Aug 2014 19:21:26 +0100 Message-ID: References: <53F247D5.4030502@redhat.com> <53F360FB.1090809@redhat.com> <53F76B51.5090709@redhat.com> <53F77BD3.6070402@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: linux-ext4@vger.kernel.org To: Eric Sandeen Return-path: Received: from mail-vc0-f170.google.com ([209.85.220.170]:62971 "EHLO mail-vc0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932410AbaHVSV1 (ORCPT ); Fri, 22 Aug 2014 14:21:27 -0400 Received: by mail-vc0-f170.google.com with SMTP id lf12so12897566vcb.1 for ; Fri, 22 Aug 2014 11:21:26 -0700 (PDT) In-Reply-To: <53F77BD3.6070402@redhat.com> Sender: linux-ext4-owner@vger.kernel.org List-ID: On 22 August 2014 18:20, Eric Sandeen wrote: > On 8/22/14, 11:40 AM, Mark Ballard wrote: >> No, Eric. I can see it's accurate in its own context. I mean accurate >> in relaying enough information to convey the situation accurately to >> the user. That requires something like e2label to see a wider context, > > so saying something like: > > "invalid superblock. This is an xfs filesystem." > > isn't sufficient? And here I thought that was a great idea ;) > > I'm not sure how much further we could reasonably go in error messages... > > At some point we have to assume some degree of administrative skill and > familiarity... Yes and there's no accounting for the stubborn incontinence of a user making indignant forays under the bonnet. It did seem reasonable to me for a moment that these disk utilities would say, e.g. ... can't operate on encrypted file system'. But I see how that might not be a reasonable expectation. The alternative is that users have to think. That's a big ask!-) ... They've got other things to think about. Mark. > > -Eric > >> and I can see that might actually be an unreasonable expectation. But >> this is what I was getting at: information accurate enough to allow >> non-educated users to get an instant grip of the environment when they >> are forced to go delving under the bonnet (hood) of their computer. >> None of the os componenets were made -- or documented -- with that >> sort of user in mind: someone with less time and experience than is >> really required to work efficiently under there. Yet the application >> environment is such a tangle that users are left with little choice >> but to get their hands dirty. And when you look under there, you see >> that it was made by Heath Robinson but that the drawings were burned >> in a fire. >> >> On 22 August 2014 17:09, Eric Sandeen wrote: >>> On 8/22/14, 9:19 AM, Mark Ballard wrote: >>>> Ya. It did look that way. 'Scuse me for not checking first. >>>> >>>> But my point is that it may still be a problem for ext4, dumpe2fs, >>>> e2fsck, fsck and presumably gparted and so on. >>>> >>>> That is, would it not be polite of them to report the error ...>>> roll>... accurately? >>> >>> Ah, I see. So you don't like "corrupted" - you'd like to know that it's >>> something else perfectly valid, just not the thing you were looking for. >>> >>> Maybe like: >>> >>> # misc/dumpe2fs /dev/sdc1 >>> dumpe2fs 1.43-WIP (09-Jul-2014) >>> misc/dumpe2fs: Superblock checksum does not match superblock while trying to open /dev/sdc1 >>> Couldn't find valid filesystem superblock. >>> /dev/sdc1 contains a xfs file system >>> >>> >>> # misc/dumpe2fs /dev/sdc >>> dumpe2fs 1.43-WIP (09-Jul-2014) >>> misc/dumpe2fs: Superblock checksum does not match superblock while trying to open /dev/sdc >>> Couldn't find valid filesystem superblock. >>> /dev/sdc is entire device, not just one partition! >>> >>> -Eric >>> >>>> (No irony intended.) >>>> >>>> >>>> On 19 August 2014 15:36, Eric Sandeen wrote: >>>>> On 8/18/14, 3:23 PM, Mark Ballard wrote: >>>>>>> I'm guessing that it's the encryption getting in your way. >>>>>> >>>>>> Cheers, Eric. Does rather look that way. But for the sake of a user report... >>>>>> >>>>>>> >>>>>>> How is /dev/sdb1 encrypted? Usually this is done with something like dm-crypt. >>>>>>> Or is it hardware encryption managed in the bios? Did you unlock it? >>>>>> >>>>>> Done with crytpsetup using luks. >>>>>> >>>>>>> >>>>>>> What does "blkid /dev/sdb1" say? >>>>>>> >>>>>> >>>>>> It says Luks. >>>>> >>>>> and not ext4 - so you need to unlock it via mumblemumbleLuksStuffmumblemumble >>>>> before you can operate on it with e2fsprogs tools. >>>>> >>>>> # cryptsetup luksOpen /dev/sdb1 ... or something. Sorry, I'm not a LUKS >>>>> expert... >>>>> >>>>> Anyway, not an ext4 problem. Your superblock isn't corrupted, it's encrypted. :) >>>>> >>>>> -Eric >>>>> >>> >