From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id F250B1381F3 for ; Tue, 3 Sep 2013 14:14:51 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B3B98E0FD0; Tue, 3 Sep 2013 14:14:41 +0000 (UTC) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9AA08E0DF6 for ; Tue, 3 Sep 2013 14:14:40 +0000 (UTC) Received: by mail-ob0-f178.google.com with SMTP id ef5so5825436obb.37 for ; Tue, 03 Sep 2013 07:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=+HihCz3tcaPEO02N3Ko0e05ZwGFK68sSkIcntyP5Qws=; b=x82w6AKqeMKBhBkcxxze/ltTOW7rRDtBkuz+X5gNgQ/osMf+onTR+2jZXEr+EnemOK Eh+KATs38Xk67niWBejHXId6fDzGJVAQ0we0QUSWbsTcaSm2E6RHfJ6yqGTuW+Q1P2EJ Dcvw9DsbCjIvbBBS1KNvN3cpWpCgiTXMldNzErEZUJ3geXdBIVBrwLFLzFb0Smhby3z0 9kxp8PbdoUPCZ9415xMW3+4uYBGdJpC1rNEqOitxn3xv05t2n6qjTrRs/jzaWfjUrF1G EKZ/Pf+pHdO2rGaZ4qmjaxDmkNFqCbLRKFHyv56ibQos4/ZeJvl3ruRzj0HwlSdaLjph T/8g== X-Received: by 10.60.62.4 with SMTP id u4mr20946841oer.35.1378217679668; Tue, 03 Sep 2013 07:14:39 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.60.52.79 with HTTP; Tue, 3 Sep 2013 07:13:59 -0700 (PDT) In-Reply-To: <52255BEF.2080000@iinet.net.au> References: <20130902161515.GA3446@solfire> <52250FF3.6050305@gmail.com> <20130903024504.GB3409@solfire> <5225525C.7070403@iinet.net.au> <20130903032621.GC3409@solfire> <52255BEF.2080000@iinet.net.au> From: Francisco Ares Date: Tue, 3 Sep 2013 11:13:59 -0300 Message-ID: Subject: Re: [gentoo-user] Re: Need help: Filesystem (ext4) corrupted! To: gentoo-user Content-Type: multipart/alternative; boundary=089e012953ba384ae504e57b4ffa X-Archives-Salt: 75196027-e5d7-4b7c-9820-2a8604a9bdac X-Archives-Hash: 8084ec0a611abeb761068d7493994c34 --089e012953ba384ae504e57b4ffa Content-Type: text/plain; charset=UTF-8 2013/9/3 William Kenworthy > On 03/09/13 11:26, meino.cramer@gmx.de wrote: > > William Kenworthy [13-09-03 05:08]: > >> On 03/09/13 10:45, meino.cramer@gmx.de wrote: > >>> walt [13-09-03 04:15]: > >>>> On 09/02/2013 09:15 AM, meino.cramer@gmx.de wrote: > >>>>> The rootfs and $HOME of my embedded system is stored > >>>>> on a 16GB SD-card (about 5GB used, rest free). The FS > >>>>> is ext4. > >>>>> > >>>>> Since the system hangs for unknown reasons several times > >>>> Does it hang at a predictable point, like during boot, or poweroff? > >>>> > >>>> I know almost nothing about SD cards (yet). Do they develop bad > >>>> blocks like other storage media? I notice fsck.ext4 has a -c flag > >>>> to check for bad blocks. > >>>> > >>> No, it hangs while compiling or while updateing (eix-sync; emerge ...). > >>> > >>> > >>> I did the following now: > >>> I did a binary image backup with dd of the sdcard. > >>> I made a backup of the all files from the bad fs with tar. > >>> I say "YES" to fsck to fix what it found. > >>> I made another backup of the all files from the bad fs with tar. > >>> I md5summed both tar archives and found them identical. > >>> > >>> Now...is the conclusion correct, that the identical md5sum > >>> indicate, that the fixed error of the fs only had impact to > >>> already invalidated data? > >>> Or whatelse could this indicate? > >>> > >>> Best regards, > >>> mcc > >>> > >>> PS: What come mind just in this moment: > >>> Can I ran fsck on an binary image of the fs which I made with dd > somehow? > >>> > >>> > >>> > >>> > >>> > >> Have you run out of inodes? - ext 4 has had very mixed success for me on > >> solid state. Running out of inodes is a real problem for gentoo on > >> smaller SD cards with standard settings. > >> > >> BillK > >> > >> > >> > > Does this error message from fsck indicate that? I am really bad in > > guessing what fsck tries to cry at me ... ;) > > > > > >>> solfire:/root>fsck.ext4 -f -p /dev/sdb2 > >>> rootfs: Inodes that were part of a corrupted orphan linked list > found. > >>> > >>> rootfs: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. > >>> (i.e., without -a or -p options) > >>> [1] 18644 exit 4 fsck.ext4 -f -p /dev/sdb2 > >>> > >>> > > Is there any way to correct the settings from the default values to > > more advances ones, which respect the sdcard size of 16GB *without* > > blanking it...a "correction on the fly" so to say??? > > > > And if not: Is there a way to backup the sdcard and playback the files > > after reformatting it by preserving all three time stamps of the > > files (atime is deactivated via fstab though) ? > > > > Best regards, > > mcc > > > > > > > > > > > df -i - if you get 100% iUSE or near to it thats your problem ... I have > seen that error message you give as a result of running out of inodes > corrupting the FS. > > No, your only way out is to copy (I use rync) the files off, recreate > the fs with max inodes ("man mke2fs") and rsync the files back. Once an > ext* fs has been created with a certain number of inodes its fixed until > you re-format. > > I get it happening regularly on 4G cards when I forget and just emerge a > couple of packages without cleaning up in between packages. On 16G > cards, its compiling something like glibc or gcc that uses huge numbers > of inodes at times. On a single 32G card I have, the standard settings > have been fine ... so far :) > > Billk > > > Just my 2 cents: while updating I think it would it be a good practice to have some sort of external storage (even networked) and do a unionfs with the working file system. Some folders inside /usr use to keep almost half (more, sometimes) of all files in my systems (like "/usr/portage" , "/usr/src" and "/usr/include" , which are not needed while not under system maintenance). Francisco --089e012953ba384ae504e57b4ffa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= 2013/9/3 William Kenworthy <billk@iinet.net.au>
On 03/09/13 11:26, meino.cramer@gmx.de wrote:
> William Kenworthy <billk@iinet.net.au> [13-09-03 05:08]:
>> On 03/09/13 10:45, meino.cramer@gmx.de wrote:
>>> walt <w41ter@gmail.com> [13-09-03 04:15]:
>>>> On 09/02/2013 09:15 AM, meino.cramer@gmx.de wrote:
>>>>> The rootfs and $HOME of my embedded system is stored >>>>> on a 16GB SD-card (about 5GB used, rest free). The FS<= br> >>>>> is ext4.
>>>>>
>>>>> Since the system hangs for unknown reasons several tim= es
>>>> Does it hang at a predictable point, like during boot, or = poweroff?
>>>>
>>>> I know almost nothing about SD cards (yet). =C2=A0Do they = develop bad
>>>> blocks like other storage media? =C2=A0I notice fsck.ext4 = has a -c flag
>>>> to check for bad blocks.
>>>>
>>> No, it hangs while compiling or while updateing (eix-sync; eme= rge ...).
>>>
>>>
>>> I did the following now:
>>> I did a binary image backup with dd of the sdcard.
>>> I made a backup of the all files from the bad fs with tar.
>>> I say "YES" to fsck to fix what it found.
>>> I made another backup of the all files from the bad fs with ta= r.
>>> I md5summed both tar archives and found them identical.
>>>
>>> Now...is the conclusion correct, that the identical md5sum
>>> indicate, that the fixed error of the fs only had impact to >>> already invalidated data?
>>> Or whatelse could this indicate?
>>>
>>> Best regards,
>>> mcc
>>>
>>> PS: What come mind just in this moment:
>>> Can I ran fsck on an binary image of the fs which I made with = dd somehow?
>>>
>>>
>>>
>>>
>>>
>> Have you run out of inodes? - ext 4 has had very mixed success for= me on
>> solid state. =C2=A0Running out of inodes is a real problem for gen= too on
>> smaller SD cards with standard settings.
>>
>> BillK
>>
>>
>>
> Does this error message from fsck indicate that? I am really bad in > guessing what fsck tries to cry at me ... ;)
>
>
>>> =C2=A0 =C2=A0 solfire:/root>fsck.ext4 -f -p /dev/sdb2
>>> =C2=A0 =C2=A0 rootfs: Inodes that were part of a corrupted orp= han linked list found.
>>>
>>> =C2=A0 =C2=A0 rootfs: UNEXPECTED INCONSISTENCY; RUN fsck MANUA= LLY.
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (i.e., without -a or -p options) >>> =C2=A0 =C2=A0 [1] =C2=A0 =C2=A018644 exit 4 =C2=A0 =C2=A0 fsck= .ext4 -f -p /dev/sdb2
>>>
>>>
> Is there any way to correct the settings from the default values to > more advances ones, which respect the sdcard size of 16GB *without* > blanking it...a "correction on the fly" so to say???
>
> And if not: Is there a way to backup the sdcard and playback the files=
> after reformatting it by preserving all three time stamps of the
> files (atime is deactivated via fstab though) ?
>
> Best regards,
> mcc
>
>
>
>
>
df -i - if you get 100% iUSE or near to it thats your problem .= .. I have
seen that error message you give as a result of running out of inodes
corrupting the FS.

No, your only way out is to copy (I use rync) the files off, recreate
the fs with max inodes ("man mke2fs") and rsync the files back. = =C2=A0Once an
ext* fs has been created with a certain number of inodes its fixed until you re-format.

I get it happening regularly on 4G cards when I forget and just emerge a couple of packages without cleaning up in between packages. =C2=A0On 16G cards, its compiling something like glibc or gcc that uses huge numbers
of inodes at times. =C2=A0On a single 32G card I have, the standard setting= s
have been fine ... so far :)

Billk



Just my=C2=A0 2 cen= ts: while updating I think it would it be a good practice to have some sort= of external storage (even networked) and do a unionfs with the working fil= e system.=C2=A0 Some folders inside /usr use to keep almost half (more, som= etimes) of all files in my systems (like "/usr/portage" , "/= usr/src" and "/usr/include" , which are not needed while not= under system maintenance).

Francisco
--089e012953ba384ae504e57b4ffa--