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 3652D1381F3 for ; Wed, 4 Sep 2013 00:22:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8C644E154C; Wed, 4 Sep 2013 00:22:41 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 18AE4E154C for ; Wed, 4 Sep 2013 00:22:38 +0000 (UTC) Received: from gmx.net ([84.133.165.142]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MRCCJ-1VQWRO1WjH-00UbQA for ; Wed, 04 Sep 2013 02:22:37 +0200 Received: by gmx.net (nbSMTP-1.00) for uid 1001 meino.cramer@gmx.de; Wed, 4 Sep 2013 02:22:37 +0200 (CEST) Date: Wed, 4 Sep 2013 02:22:36 +0200 From: meino.cramer@gmx.de To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Need help: Filesystem (ext4) corrupted! Message-ID: <20130904002236.GA3788@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> 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 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: mutt-ng/devel-r804 (Linux) X-Provags-ID: V03:K0:te1/PhngreV6nMToTi/xAZ87foIinj/GdXbJU26CCd0MAEmnC2S VZsVFC60HL4MMRRnsVPe2fPZZc+Nc0BIz+xHObp6Ir/m1jeAZvfEI9L5a1dNjkm49Ntcnyj AqXQ39FHEvxiwTFjrlZ7YwI4gjwgcHbaAhseQW56vWYZPorp3LSxRTXAjhRPcNQlQraOysa sibWkLbXAiHfiBiEAw44Q== X-Archives-Salt: ed491e29-1dae-44ea-9a0d-8c90cd95ef54 X-Archives-Hash: a60f5fa8dc9ec45cd12b71e6e4f0ed25 Francisco Ares [13-09-04 02:08]: > 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 powero= ff? > > > >>>> > > > >>>> I know almost nothing about SD cards (yet). Do they develop bad > > > >>>> blocks like other storage media? I notice fsck.ext4 has a -c fl= ag > > > >>>> 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 li= st > 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 fi= les > > > > 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 h= ave > > > 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 un= til > > > you re-format. > > > > > > I get it happening regularly on 4G cards when I forget and just emerg= e a > > > couple of packages without cleaning up in between packages. On 16G > > > cards, its compiling something like glibc or gcc that uses huge numbe= rs > > > of inodes at times. On a single 32G card I have, the standard settin= gs > > > 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 > > > > > > >=20 > There are some parameters for creating a better backup archive using tar, > like --same-owner and --atime- preserve. >=20 > 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. >=20 > G=F3od luck > Francisco Hi Francisco, as I understand the man page, --same-owner is only activ while extracting a tar: --same-owner create extracted files with the same ownership while extracting I always use --preserve like --preserve-permissions plus --same-order =2E Atime setting is disabled via fstab on my embedded system for two reasons: Performance wise since any access to a file will trigger a write action to the flash chip even when reading the file. Any write action to a flash chip wear out the chip -- it has a limited=20 number of write cycles. I also disbaled atime on my PC for the first reason. What makes the unionfs'ed nfs mount of my PC on the embedded system interesting to you ? (sorry if this question sounds bad/negative/... or so...its my limited english. Its simply and only a question and the wish of getting more infos... :) Best regards, mcc