Find the answer to your Linux question:
Results 1 to 9 of 9
I'm running Puppeee on an EeePC 701, but I'm assuming that my question probably applies to Linux in general. On my EeePC, I usually write all my data to an ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jan 2011
    Posts
    11

    Data loss due to mounting issue?


    I'm running Puppeee on an EeePC 701, but I'm assuming that my question probably applies to Linux in general.

    On my EeePC, I usually write all my data to an SD Card, so I can eaily swap with my main laptop. Before accessing the SD Card, I need to mount it, so it will become accessible unter /mnt/SDCARD.

    Last time, I used the word processor without mounting my SD Card. I was in a hurry to start a new project, and didn't pay too much attention to where the file was saved. I DID make sure that my new project (several hours of work) was saved without errors - so I was sure I could retrieve my document next time (finding the save location through a file search, if necessary).

    Yesterday, I started up my EeePC, but the document I created was nowhere to be found. I went through the process again, and discovered that my text program was saving to /mnt/SDCARD anyway, and I could see my test file right in that folder, which showed up after saving to it. So to experiment, I mounted the SD Card, and the contents of my SD Card now showed up unter /mnt/SDCARD *instead* of my test file. I then unmounted the SD Card, and there was my test file again.

    Next thing I did was to restart the computer. Result: The test file was gone, and nowhere to be found! Can anybody tell me what's going on, if it's possible to retrieve my test file and the original document I had been working on, or if they are now gone for good?

    Thanks!

  2. #2
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,345
    If you write to a directoy which then later gets used as a mount point, the files are not lost.
    After unmounting they will be visible again, just as you experienced.

    You say, the files are gone after reboot.
    This might be, if /mnt is in a ramdisk or /mnt getīs cleaned up on shutdown/reboot.
    In this case, your files are gone.

    I am not familiar with puppeee, but maybe this can help to get some informations:
    Code:
    cat /etc/fstat
    mount
    You must always face the curtain with a bow.

  3. #3
    Just Joined!
    Join Date
    Jan 2011
    Posts
    11
    Thanks for the reply. I'm afraid there is no /etc/fstat on my system, though.

    EDIT: Or did you mean fstab?

  4. #4
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,345
    Sorry, typo.
    Should read: /etc/fstab
    You must always face the curtain with a bow.

  5. #5
    Just Joined!
    Join Date
    Jan 2011
    Posts
    11
    Got it. So does this tell you anything?

    # cat /etc/fstab
    none /proc proc defaults 0 0
    none /sys sysfs defaults 0 0
    none /dev/pts devpts gid=2,mode=620 0 0
    /dev/fd0 /mnt/floppy auto noauto,rw 0 0
    # mount
    rootfs on / type rootfs (rw,relatime)
    /dev/sda1 on /initrd/mnt/dev_save type ext4 (rw,noatime,barrier=1,data=ordered)
    /dev/loop1 on /initrd/pup_ro1 type ext3 (rw,noatime,barrier=1,nodelalloc,data=ordered)
    tmpfs on /initrd/pup_rw type tmpfs (rw,relatime,size=510224k)
    tmpfs on /initrd/mnt/tmpfs type tmpfs (rw,relatime,size=109308k)
    /dev/loop0 on /initrd/pup_ro2 type squashfs (ro,noatime)
    tmpfs on /initrd/mnt/tmpfs2 type tmpfs (rw,relatime,size=7520k)
    /dev/loop3 on /initrd/pup_z type squashfs (ro,noatime)
    unionfs on / type aufs (rw,relatime,si=a9e3e07c)
    tmpfs on /mnt/unrootfs type tmpfs (rw,relatime,size=4096k)
    none on /proc type proc (rw,relatime)
    none on /dev/pts type devpts (rw,relatime,gid=2,mode=620)
    none on /sys type sysfs (rw,relatime)
    none on /dev/shm type tmpfs (rw,relatime)
    none on /proc/bus/usb type usbfs (rw,relatime)

  6. #6
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,345
    Hmm, I just learned from here
    FAQ - Puppeee Linux
    that puppeee has two ways of installing: frugal and full

    Looking at the number of tmpfs mounts and the readonly loopmounted image with a squashfs,
    you probably have the frugal install.

    Which in turn means, that most of puppee is in ram and therefore volatile.

    From the faq:
    - You can lose work if your computer loses power or crashes and you haven't saved. (Pupmode 13 only)
    - Filesystem corruption, and problems with the layering can occur, you should make backups often.

    - All your personal files go into one save file, which is very simple and fast to back up and restore.

    Especially the last point. As far as I understood you dont use that "save file", but rather a manually mounted sd card.


    As I said, Iīm not using puppeee, so you probably want to doublecheck with s/o else here or at the puppeee forum.
    But my guess so far is, that your files are gone. Sorry.
    You must always face the curtain with a bow.

  7. #7
    Just Joined!
    Join Date
    Jan 2011
    Posts
    11
    Well, my guess is that the files are gone as well, but I'd like to make sure, and also, I want to learn from the incident so it doesn't happen again.

    One thing I'm fairly sure about, though, is that I have a full install.

  8. #8
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,345
    The fstab and mount data indicates a frugal install:
    1) / is on a rootfs
    rootfs on / type rootfs (rw,relatime)

    from the kernel documentation:
    /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt
    What is rootfs?
    ---------------

    Rootfs is a special instance of ramfs (or tmpfs, if that's enabled), which is
    always present in 2.6 systems. You can't unmount rootfs for approximately the
    same reason you can't kill the init process; rather than having special code
    to check for and handle an empty list, it's smaller and simpler for the kernel
    to just make sure certain lists can't become empty.

    Most systems just mount another filesystem over rootfs and ignore it. The
    amount of space an empty instance of ramfs takes up is tiny.
    2) Some loopmounted images. Just one is writeable, probably for logs, tmp files, etc
    /dev/loop0 on /initrd/pup_ro2 type squashfs (ro,noatime)
    /dev/loop1 on /initrd/pup_ro1 type ext3 (rw,noatime,barrier=1,nodelalloc,data=ordered)
    /dev/loop3 on /initrd/pup_z type squashfs (ro,noatime)

    3) Four ramdisks
    tmpfs on /initrd/pup_rw type tmpfs (rw,relatime,size=510224k)
    tmpfs on /initrd/mnt/tmpfs type tmpfs (rw,relatime,size=109308k)
    tmpfs on /initrd/mnt/tmpfs2 type tmpfs (rw,relatime,size=7520k)
    tmpfs on /mnt/unrootfs type tmpfs (rw,relatime,size=4096k)

    4) A unionfs layer to make the whole filesystem appear writeable. In reality, most writes will go to the ramdisks
    unionfs on / type aufs (rw,relatime,si=a9e3e07c)

    I am not clear on the details yet, but a full install to a disk would not have such a rather complicated setup.


    As for the future:
    Probably the full install would be a start.
    Then the files would have survived the reboot.

    Other than that: Maybe you have a local fileserver in your network or maybe go with the latest hype and save to "The Cloud(tm)"
    You must always face the curtain with a bow.

  9. #9
    Just Joined!
    Join Date
    Jan 2011
    Posts
    11
    Ok thanks. Sad, but thanks anyway.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •