Francisco Ares <[email protected]> [13-09-04 02:08]:
> Em 03/09/2013 13:12, <[email protected]> escreveu:
> >
> > William Kenworthy <[email protected]> [13-09-03 17:16]:
> > > On 03/09/13 11:26, [email protected] wrote:
> > > > William Kenworthy <[email protected]> [13-09-03 05:08]:
> > > >> On 03/09/13 10:45, [email protected] wrote:
> > > >>> walt <[email protected]> [13-09-03 04:15]:
> > > >>>> On 09/02/2013 09:15 AM, [email protected] 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
> > >
> > >
> >
> > 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 <backup file> <root of embedded system>
> >
> > 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óod 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
. 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
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
