All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: tytso@mit.edu, kernel list <linux-kernel@vger.kernel.org>
Subject: Re: ext4: total breakdown on USB hdd, 3.0 kernel
Date: Thu, 26 Jun 2014 22:50:49 +0200	[thread overview]
Message-ID: <20140626205049.GA11577@xo-6d-61-c0.localdomain> (raw)
In-Reply-To: <20140626203052.GA9449@xo-6d-61-c0.localdomain>

On Thu 2014-06-26 22:30:52, Pavel Machek wrote:
> Hi!
> 
> > Ok, this ext4 filesystem does _not_ have easy life: it is in usb envelope, I wanted
> > to use it as a root filesystem, and it is connected to OLPC-1.75, running some kind
> > of linux-3.0 kernels.
> > 
> > So power disconnects are common, and even during regular reboot, I hear disk doing
> > emergency parking.
> > 
> > I don't know how barriers work over USB...
> > 
> > Plus the drive has physical bad blocks, but I attempted to mark them with fsck -c.
> > 
> > OTOH, it is just a root filesystem... and nothing above should prevent correct operation
> > (right?)
> > 
> > On last mount, it remounted itself read-only, so there's time for fsck, I guess...
> > 
> > But I believe this means I am going to lose all the data on the filesystem, right?
> 
> It looks like the filesystem contains _way_ too many 0xffff's:
> 
> Inode 655221 has compression flag set on filesystem without compression support.  Clear<y>? yes
> 
> Inode 655221 has INDEX_FL flag set but is not a directory.
> Clear HTree index<y>? yes
...

And for every bug in kernel, there's one in fsck: I did not expect it, but fsck actually
suceeded, and marked fs as clean. But second fsck had issues with /lost+found...


-bash-4.1# fsck  /dev/sdc4 
fsck from util-linux-ng 2.18
e2fsck 1.41.12 (17-May-2010)
armroot: clean, 132690/985424 files, 1023715/3934116 blocks
-bash-4.1# fsck -f /dev/sdc4 
fsck from util-linux-ng 2.18
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
'..' in /lost+found/#652090/auth-for-pavel-wzJd6X (17) is /lost+found (11), should be /lost+found/#652090 (652090).
Fix<y>? yes

Pass 4: Checking reference counts
Pass 5: Checking group summary information

armroot: ***** FILE SYSTEM WAS MODIFIED *****
armroot: 132690/985424 files (0.1% non-contiguous), 1023715/3934116 blocks
-bash-4.1# 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2014-06-26 20:50 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-26 20:20 ext4: total breakdown on USB hdd, 3.0 kernel Pavel Machek
2014-06-26 20:30 ` Pavel Machek
2014-06-26 20:50   ` Pavel Machek [this message]
2014-06-27  2:48     ` Theodore Ts'o
2014-06-27  2:46   ` Theodore Ts'o
2014-06-29 20:25     ` Pavel Machek
2014-06-29 21:04       ` Theodore Ts'o
2014-06-30  6:46         ` Pavel Machek
2014-06-30 13:43           ` Theodore Ts'o
2014-07-04 10:23             ` ext4: media error but where? Pavel Machek
2014-07-04 12:11               ` Theodore Ts'o
2014-07-04 17:21                 ` Pavel Machek
2014-07-04 18:06                   ` Pavel Machek
2014-07-04 18:56                   ` Theodore Ts'o
2014-07-06 13:32                     ` Pavel Machek
2014-07-06 13:43                       ` Pavel Machek
2014-07-06 18:29                         ` Theodore Ts'o
2014-07-06 21:37                           ` Pavel Machek
2014-07-07  1:00                             ` Theodore Ts'o
2014-07-07 18:55                               ` Pavel Machek
2014-07-07 23:18                                 ` 3.16-rc, ext4: oopses, OOMs after hard powerdown Pavel Machek
2014-07-07 23:21                                 ` ext4: media error but where? Theodore Ts'o
2014-07-04 19:17                   ` Andreas Dilger
2014-07-04 20:33                     ` Pavel Machek
2014-07-04 22:18                       ` Andreas Dilger
2014-07-05 22:17                       ` Theodore Ts'o
2014-06-27  8:23 ` ext4: total breakdown on USB hdd, 3.0 kernel Oliver Neukum

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=20140626205049.GA11577@xo-6d-61-c0.localdomain \
    --to=pavel@ucw.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@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.