wachsendes image-file mounten

[mahlzeit]

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 :)

[bla!zilla]

Schreibt eine Anwendung fortlaufend in die Datei? Wenn ja, wird das mit dem mounten problematisch. Eine "Containerdatei" legst du sehr einfach mit dd an.



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.

[mahlzeit]

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 !!!!

[bla!zilla]

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.

[anda_skoa]

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,
_

[mahlzeit]

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

[peschmae]

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ä

[bla!zilla]

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.

[anda_skoa]

Ich dachte eher an LVM als Alternative zu einem Image.

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

Ciao,
_

[peschmae]

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ä

[bla!zilla]

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. ;)



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....

[mahlzeit]

nö hab sowieso im sinn ein paar gigs grosses image um darin meine vielen websites unterzubringen

[bla!zilla]

Dann ist das ja kein Problem bei dir. :)