Anzeige:
Ergebnis 1 bis 13 von 13

Thema: wachsendes image-file mounten

  1. #1
    Registrierter Benutzer
    Registriert seit
    06.09.2006
    Beiträge
    9

    wachsendes image-file mounten

    hallo liebe computerer.

    könnt ihr mir bitte helfen bei folgendem:

    ich möchte ein image-file anlegen, welches nach und nach wächst und ich an einen bestimmten punkt mounten kann.
    wichtig wäre, dass das dateisystem extrem viele ordner und dateien zulässt und nicht so schnell an grenzen stösst.

    es muss irgendwie mit dem loop-device gehen aber ich kriegs nicht so richtig raus, wie ich so ein image erstmal anlege und dann richtig mounte.

    wäre der hammer, wenn mir einer von den pro´s hierbei kurz helfen könnte.

    vielen dank schonmal fürs lesen meines problems

  2. #2
    Registrierter Benutzer
    Registriert seit
    03.08.2004
    Beiträge
    132
    Schreibt eine Anwendung fortlaufend in die Datei? Wenn ja, wird das mit dem mounten problematisch. Eine "Containerdatei" legst du sehr einfach mit dd an.

    Code:
    patrick@starcat:/tmp> dd if=/dev/zero of=datei bs=1M count=10
    10+0 Datensätze ein
    10+0 Datensätze aus
    10485760 Bytes (10 MB) kopiert, 0,0952104 s, 110 MB/s
    patrick@starcat:/tmp> sudo /sbin/mkfs.ext3 datei
    mke2fs 1.39 (29-May-2006)
    datei is not a block special device.
    Proceed anyway? (y,n) y
    Filesystem label=
    OS type: Linux
    Block size=1024 (log=0)
    Fragment size=1024 (log=0)
    2560 inodes, 10240 blocks
    512 blocks (5.00%) reserved for the super user
    First data block=1
    Maximum filesystem blocks=10485760
    2 block groups
    8192 blocks per group, 8192 fragments per group
    1280 inodes per group
    Superblock backups stored on blocks:
            8193
    
    Writing inode tables: done
    Creating journal (1024 blocks): done
    Writing superblocks and filesystem accounting information: done
    
    This filesystem will be automatically checked every 36 mounts or
    180 days, whichever comes first.  Use tune2fs -c or -i to override.
    patrick@starcat:/tmp> sudo mount -o loop datei /media/dvd/
    patrick@starcat:/tmp> mount | grep datei
    /tmp/datei on /media/dvd type ext3 (rw,loop=/dev/loop0)
    patrick@starcat:/tmp>
    Schon hast du eine Containerdatei mit 10MB und einem ext3 Dateisystem die sich mounten lässt.

  3. #3
    Registrierter Benutzer
    Registriert seit
    06.09.2006
    Beiträge
    9
    vielen dank. das hilft mir schonmal um ein wenig weiterzukommen.

    ist es irgendwie möglich, dass die container-datei "wächst" wenn mehr daten dazukommen?

    und wie kann ich erreichen, dass die container-datei Extrem viele dateien verkraftet? (viele textfiles - zigtausende)

    die datei würde dann ein gemountet werden und in apache als document-root gesetzt werden.

    ich möchte das machen, damit ich schneller ein backup des ganzen webservers ziehen kann.

    big THX !!!!

  4. #4
    Registrierter Benutzer
    Registriert seit
    03.08.2004
    Beiträge
    132
    Wieviele Dateien du verwalten kannst, hängt vom verwendeten Dateisystem ab. Ich würde dir da ReiserFS empfehlen. AFAIK können "Containerdateien" nicht wachsen. Die legt man einmal an und dann benutzt man sie halt bis sie voll sind.

  5. #5
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Ansich müßte ein Programm eine Datei, die sie zum Schreiben geöffnet hat, auch vergrößern können.

    Wenn das darin befindliche Dateisystem ein Online-Growing unterstützt, zb XFS, sollte die Aufgabenstellung schon lösbar sein.

    Allerdings hört sich das für mich mehr nach einem Fall für LVM und LVM Snapshots an

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  6. #6
    Registrierter Benutzer
    Registriert seit
    06.09.2006
    Beiträge
    9
    ich weiss nur bei K3B wird ein "growisofs" verwendet, wenn man daten-discs on-the-fly brennt...

    aber im grunde könnte ich mit einer fix vorgebenen container-grösse leben.

    und ihr meint mit REISERFS formatiert, stosse ich nicht so schnell an die grenzen des filesystems.

    danke erstmal. ihr habt mir gut geholfen.

    wenn jemandem noch was einfällt- immer her damit

    ciao und danke

  7. #7
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    Die Conteinerdatei nachträglich zu vergrössern geht problemlos, wie anda_skoa erwähnt hat. Hab ich auch schon ein paar mal gemacht; vor allem zu der zeit als es das Crypto-Fuse-Ding noch nicht gab.

    Eigentlich ganz einfach - etwa so hab ich das jeweils gemacht:
    1) erstellen des Images: dd if=/dev/zero of=datei bs=1M count=10
    2) Dateisystem drauf: mkfs.reiserfs -f datei
    3) benutzen
    4) erstellen einer Imagekopie die grösser ist (sicherheitshalber, dann hat man gleich noch das Originalimage als Backup): cat datei /dev/zero | dd of=datei.neu bs=1M count=20; mv datei datei.old; mv datei.neu datei
    5) resizefs_reiserfs datei

    irgendwo hats afair jeweils geklemmt - ich glaube das zweite dd hat irgendwie Ärger gemacht und die Blocks etwas merkwürdig gezählt oder so.
    Genau, hab das schnell noch mal getestet - keine Ahnung wieso dass das da nicht zufrieden ist. Hab das dann jeweils so gelöst dass ich defacto ein "cat datei /dev/zero > datei.neu" gemacht habe; welches ich händisch zum rechten Zeitpunkt beendet habe, bevor die datei.neu all zu gross wurde.

    Abgesehen davon (weiss einer wieso das nicht lieb ist?) kein Problem.

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  8. #8
    Registrierter Benutzer
    Registriert seit
    03.08.2004
    Beiträge
    132
    Zitat Zitat von anda_skoa Beitrag anzeigen
    Allerdings hört sich das für mich mehr nach einem Fall für LVM und LVM Snapshots an
    Gut, ich bin jetzt nicht davon ausgegangen das jemand innerhalb einer Containerdatei noch LVM nutzen will.

    Aber so wie es peschmae vorgeschlagen hat, sollte es klappen.

  9. #9
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Ich dachte eher an LVM als Alternative zu einem Image.

    Einen momentanen Filesystemzustand zu sichern hört sich einfach nach LVM Snapshot an.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  10. #10
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    Achso, stimmt, den Post hatte ich gar nicht gelesen. In dem Falle würde ich natürlich auch zu LVM greifen.

    (Auch wenn ich für mich zuhause davon abgekommen bin - irgendwie hab ich mein Script nie richtig zum laufen gebracht, wenn ichs von Hand machte gings aber immer reibungslos mit den Snapshots - auf jeden Fall ein cooles Feature)

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  11. #11
    Registrierter Benutzer
    Registriert seit
    03.08.2004
    Beiträge
    132
    Achtet beim erstellen der Containerdatei auf die Blockgröße. Bei einer 10MB Containerdatei sind keine 4k Blöcke drin, da muss man mit 1k Blöcken arbeiten. Und dann gehen rund 8 MB für das Journal weg. Also think big, da fällt das Journal nicht so ins Gewicht.

    Verzeih mir, aber ich habe da noch zwei, drei kleine Sachen korrigiert.

    Code:
    starcat:/tmp # dd if=/dev/zero of=test.dat bs=1M count=10
    10+0 records in
    10+0 records out
    10485760 bytes (10 MB) copied, 0.0908076 s, 115 MB/s
    starcat:/tmp # mkfs.reiserfs -b 1024 -f test.dat
    mkfs.reiserfs 3.6.19 (2003 www.namesys.com)
    
    A pair of credits:
    Jeremy  Fitzhardinge  wrote  the  teahash.c  code  for  V3.  Colin  Plumb  also
    contributed to that.
    
    The  Defense  Advanced  Research  Projects Agency (DARPA, www.darpa.mil) is the
    primary sponsor of Reiser4.  DARPA  does  not  endorse  this project; it merely
    sponsors it.
    
    
    test.dat is not a block special device
    Continue (y/n):y
    Guessing about desired format.. Kernel 2.6.19.1 is running.
    Format 3.6 with standard journal
    Count of blocks on the device: 10240
    Number of blocks consumed by mkreiserfs formatting process: 8194
    Blocksize: 1024
    Hash function used to sort names: "r5"
    Journal Size 8126 blocks (first block 66)
    Journal Max transaction length 256
    inode generation number: 0
    UUID: c82004bd-36e8-4a9b-92e6-cedd0bb732de
    Initializing journal - 0%....20%....40%....60%....80%....100%
    Syncing..ok
    ReiserFS is successfully created on test.dat.
    starcat:/tmp # cat test.dat /dev/zero | dd of=test-groessere.dat count=40000
    40000+0 records in
    40000+0 records out
    20480000 bytes (20 MB) copied, 0.879126 s, 23.3 MB/s
    starcat:/tmp # resize_reiserfs test-groessere.dat
    resize_reiserfs 3.6.19 (2003 www.namesys.com)
    
    ReiserFS report:
    blocksize             1024
    block count           20000 (10240)
    free blocks           11805 (2046)
    bitmap block count    3 (2)
    
    Syncing..done
    
    
    resize_reiserfs: Resizing finished successfully.
    
    starcat:/tmp #
    Irgendwie wird mir gerade bewusst was man für ekelhafte Sauereien mit Linux machen kann....
    Geändert von bla!zilla (14-01-2007 um 19:51 Uhr)

  12. #12
    Registrierter Benutzer
    Registriert seit
    06.09.2006
    Beiträge
    9
    nö hab sowieso im sinn ein paar gigs grosses image um darin meine vielen websites unterzubringen

  13. #13
    Registrierter Benutzer
    Registriert seit
    03.08.2004
    Beiträge
    132
    Dann ist das ja kein Problem bei dir.

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •