Francisco Ares <frares@gmail.com> [13-09-04 02:08]:

> Em 03/09/2013 13:12, <meino.cramer@gmx.de> escreveu:
> >
> > William Kenworthy <billk@iinet.net.au> [13-09-03 17:16]:
> > > 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
> > > >>>>> 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