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 8C7C41381F3 for ; Tue, 3 Sep 2013 23:26:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E46C0E14E6; Tue, 3 Sep 2013 23:26:40 +0000 (UTC) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CC0A9E14C7 for ; Tue, 3 Sep 2013 23:26:39 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id f4so7452722oah.25 for ; Tue, 03 Sep 2013 16:26: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:date:message-id:subject:from:to :content-type; bh=/oT2IlVcowNJZYsFO5Lar0Cr0BlIJxDSKT+R5221Izk=; b=UnB/ctzNApj9+TRc95m1RAmfni7v2DtT25EStfZPWvmvUvi2gfL0i7Kq/XUchVfSxN E++QZtQMx8R+G2uyAdHXIS0ZE4r8F4I98kuK+j/ir4B5+WbSoYusET44lgzu2apodqk+ XW0w+CX8yLIhGbzVdJlELVJ7cWWCbAAXn2oGtAzbGIcMUTK1Y2jyZtPRB+2/coQ4T2KO R1vX//Ykh7HHV7ue4s5JUob5/EtifuoA5tmoSK6VSL9x5Xis7r6Y80HdiuQznGtEMVxS OudLVmtRXkMRlj711zwbZdT8W2cGqegz5ijiqN2wx2fcHRK/JqLSN7Y2U116hsCdG3o9 RJcg== 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 X-Received: by 10.182.101.165 with SMTP id fh5mr22958123obb.58.1378250798976; Tue, 03 Sep 2013 16:26:38 -0700 (PDT) Received: by 10.60.52.79 with HTTP; Tue, 3 Sep 2013 16:26:38 -0700 (PDT) Received: by 10.60.52.79 with HTTP; Tue, 3 Sep 2013 16:26:38 -0700 (PDT) In-Reply-To: <20130903161120.GC3916@solfire> References: <20130902161515.GA3446@solfire> <52250FF3.6050305@gmail.com> <20130903024504.GB3409@solfire> <5225525C.7070403@iinet.net.au> <20130903032621.GC3409@solfire> <52255BEF.2080000@iinet.net.au> <20130903161120.GC3916@solfire> Date: Tue, 3 Sep 2013 20:26:38 -0300 Message-ID: Subject: Re: [gentoo-user] Re: Need help: Filesystem (ext4) corrupted! From: Francisco Ares To: gentoo-user Content-Type: multipart/alternative; boundary=e89a8f6436d248d69604e583059c X-Archives-Salt: 95aa0e7b-a2f9-465c-85e3-33226784094a X-Archives-Hash: 666f6b53cf80a28c85cf253db5964ab3 --e89a8f6436d248d69604e583059c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Em 03/09/2013 13:12, escreveu: > > William Kenworthy [13-09-03 17:16]: > > 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 file= s > > > 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 hav= e > > 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 a= n > > ext* fs has been created with a certain number of inodes its fixed unti= l > > 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 > > > > > > df -i gives the following: > > rootfs 971040 352208 618832 37% / > /dev/root 971040 352208 618832 37% / > devtmpfs 63420 434 62986 1% /dev > tmpfs 63456 389 63067 1% /run > shm 63456 1 63455 1% /dev/shm > cgroup_root 63456 6 63450 1% /sys/fs/cgroup > /dev/mmcblk0p1 0 0 0 - /boot > > > You mentioned rsync to backup... > > I used > > sudo tar cvf > > the rootfs has only one partition... > > Is it alos ok to use tar or is there any drawback....? > > Best regards, > mcc > > > There are some parameters for creating a better backup archive using tar, like --same-owner and --atime- preserve. By the way, it would be an interesting project to export some folders on your home computer using nfs, tuneling it through ssh, monting it locally in your embedded computer, and applying an unionfs to the rootfs. Just dreaming, of course. G=C3=B3od luck Francisco --e89a8f6436d248d69604e583059c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Em 03/09/2013 13:12, <meino.crame= r@gmx.de> escreveu:
>
> William Kenworthy <billk@iine= t.net.au> [13-09-03 17:16]:
> > On 03/09/13 11:26, meino.c= ramer@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 i= s stored
> > >>>>> on a 16GB SD-card (about 5GB used, rest free= ). The FS
> > >>>>> is ext4.
> > >>>>>
> > >>>>> Since the system hangs for unknown reasons s= everal times
> > >>>> 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; 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 wit= h tar.
> > >>> I say "YES" to fsck to fix what it found.<= br> > > >>> I made another backup of the all files from the bad = fs with tar.
> > >>> I md5summed both tar archives and found them identic= al.
> > >>>
> > >>> Now...is the conclusion correct, that the identical = md5sum
> > >>> indicate, that the fixed error of the fs only had im= pact 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 s= uccess for me on
> > >> solid state. =C2=A0Running out of inodes is a real probl= em 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 ... ;)
> > >
> > >
> > >>> =C2=A0 =C2=A0 solfire:/root>fsck.ext4 -f -p /dev/= sdb2
> > >>> =C2=A0 =C2=A0 rootfs: Inodes that were part of a cor= rupted orphan linked list found.
> > >>>
> > >>> =C2=A0 =C2=A0 rootfs: UNEXPECTED INCONSISTENCY; RUN = fsck MANUALLY.
> > >>> =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 va= lues to
> > > more advances ones, which respect the sdcard size of 16GB *w= ithout*
> > > 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 in= odes
> > corrupting the FS.
> >
> > No, your only way out is to copy (I use rync) the files off, recr= eate
> > the fs with max inodes ("man mke2fs") and rsync the fil= es back. =C2=A0Once an
> > ext* fs has been created with a certain number of inodes its fixe= d until
> > you re-format.
> >
> > I get it happening regularly on 4G cards when I forget and just e= merge a
> > couple of packages without cleaning up in between packages. =C2= =A0On 16G
> > cards, its compiling something like glibc or gcc that uses huge n= umbers
> > of inodes at times. =C2=A0On a single 32G card I have, the standa= rd settings
> > have been fine ... so far :)
> >
> > Billk
> >
> >
>
> df -i gives the following:
>
> rootfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 971040 352208 =C2=A0 618832 = =C2=A0 37% /
> /dev/root =C2=A0 =C2=A0 =C2=A0 =C2=A0971040 352208 =C2=A0 618832 =C2= =A0 37% /
> devtmpfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A063420 =C2=A0 =C2=A0434 =C2= =A0 =C2=A062986 =C2=A0 =C2=A01% /dev
> tmpfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 63456 =C2=A0 =C2=A0389= =C2=A0 =C2=A063067 =C2=A0 =C2=A01% /run
> shm =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 63456 =C2=A0 =C2= =A0 =C2=A01 =C2=A0 =C2=A063455 =C2=A0 =C2=A01% /dev/shm
> cgroup_root =C2=A0 =C2=A0 =C2=A0 63456 =C2=A0 =C2=A0 =C2=A06 =C2=A0 = =C2=A063450 =C2=A0 =C2=A01% /sys/fs/cgroup
> /dev/mmcblk0p1 =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A00 =C2= =A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 - /boot
>
>
> You mentioned rsync to backup...
>
> I used
>
> =C2=A0 =C2=A0 sudo tar cvf <backup file> <root of embedded sy= stem>
>
> the rootfs has only one partition...
>
> Is it alos ok to use tar or is there any drawback....?
>
> Best regards,
> mcc
>
>
>

There are some parameters for creating a better backup archive using tar= , like --same-owner and --atime- preserve.

By the way, it would be an interesting project to export some folders on= your home computer using nfs, tuneling it through ssh, monting it locally = in your embedded computer, and applying an unionfs to the rootfs.=C2=A0 Jus= t dreaming, of course.

G=C3=B3od luck
Francisco

--e89a8f6436d248d69604e583059c--