Suche Möglichkeit für virtuelle Festplatte unter Win7

[Da D. (dieter)]

Moin allerseits,

ich stehe vor folgendem Problem:

Ich habe einige Ordner, die auf ein Netzlaufwerk kopiert werden sollen. 
Diese enthalten allerdings >100k Dateien von weniger als einem KB. 
Dadurch wird das ganze extrem langsam. Die Nettodatenrate ist irgendwo 
bei 7 KB/s.

Meine Idee zur Lösung:

Da die Dateien auf dem Zielsystem nicht gelesen werden brauchen, könnte 
ich sie in eine Container-Datei packen, welche auf dem Networkshare 
liegt. So braucht nur noch eine Datei übertragen werden. Und wenns gut 
läuft, sind die Daten in dem Container bereits komprimiert, so dass die 
Datenmenge, die übers Netz muss, nochmal kleiner wird.

Ich suche also eine Containerlösung die folgendes kann:

- Mounten des Containers, so dass das kopierende Programm nichts vom 
Container wissen muss.
- Direktes Arbeiten auf dem Container, ohne lokale temp Dateien. Alle 
Daten lokal zusammen packen und dann rüber schieben geht leider aus 
Platzgründen nicht. Ansonsten hätte ich einfach ein Skript + ZIP 
genommen.
- Dynamische Containergröße (auch Verkleinerung!)

Was ich bisher gefunden habe:

- Virtual Disc funktion von Win7: Leider wächst der Container nur.
- Truecrypt Container: Auch hier kein freigeben von leerem Speicherplatz 
möglich.
- einfaches ZIP:  braucht lokal Speicherplatz zum zusammen packen.

Was gibt es sonst noch? Hat jemand eine Idee was für ein Tool ich nutzen 
könnte?

Gruß,
Dieter

[Harri (Gast)]

Das dürfte wegen der geforderten Verleinerungs-Option schwierig werden.
Damit deim Programm direkt mit dem Container arbeiten kann, muss der ein 
zugreifbares Dateisystem enthalten und als Laufwerksbuchstabe 
auftauchen.

Dateisysteme unter Windows 7 wären FAT32 und NTFS. NTFS kann mit 
Bordmitteln verkleinert werden, dazu muss das Laufwerk aber 
defragmentiert werden. Das könnte genauso lange dauert wie alle Dateien 
in einen neuen Container zu kopieren :-(
Erst danach darf ein Tool außen rum deinen Container verkleinern.
Beim Schritt von VMware ESXi 5.0 zu 5.1 wurde diese Option entfernt, 
weil wohl zu viele Admins die Container verkleinert hatten ohne vorher 
das Dateisystem anzupassen. Das war denen wohl auch für die Nutzung 
durch Profis zu riskant.

Schau dir mal die virtuellen Laufwerke von Virtualbox an. Evtl. bietet 
das die Option ein virtuelles Laufwerk in Host-OS zu mounten und auch zu 
verkleinern. VMware Workstation kann sowas, kostet aber.

[(prx) A. K. (prx)]

Da Dieter schrieb:
> Ich habe einige Ordner, die auf ein Netzlaufwerk kopiert werden sollen.
> Diese enthalten allerdings >100k Dateien von weniger als einem KB.
> Dadurch wird das ganze extrem langsam. Die Nettodatenrate ist irgendwo
> bei 7 KB/s.

Arbeiten mit >100k Files in einem einzigen Verzeichnis (nicht:Baum) ist 
ziemlich spassbefreit. Egal was drunter sitzt und ob über Netz oder 
nicht. Spätestens wenn man den Fehler macht, den Explorer drauf 
anzusetzen.

Normalerweise ist man besser dran, wenn man diese Situation bereits im 
Vorfeld durch bessere Organisation der Daten vermeidet.

[(prx) A. K. (prx)]

Kleiner Test, 100k Files sequentiell durchnummeriert. Testmaschinen:
- Client 1 Windows 7, Intel 3,3GHz Sandy Bridge
- Client 2 Linux, AMD 2,7GHz single core
- Server Linux, Samba 3.6, AMD circa Atom-Klasse

Auf Client 1 HDD lokal anlegen: 107s
Auf Client 1 HDD lokal löschen: 15s

Auf Server HDD lokal anlegen: ext4:5s, btrfs:8s
Auf Server HDD lokal löschen: ext4:5s, btrfs:7s

Vom Client 1 aus per SMBv2 auf Server anlegen: ~1800s extrapoliert
Von Client 2 aus per NFS   auf Server anlegen: 210s

Auf Client 1 lokal zippen und auf Server kopieren: 14s
Auf Client 1 per SMBv2 auf Server zippen:          220s extrapoliert

Empfehlung also: lokal zippen, ggf. portionsweise.
Transaktionsverarbeitung per Netzwerk vermeiden.
Linux verwenden. ;-)

[Paul B. (paul_baumann)]

Alle Dateien mit Zip zusammenpacken, übertragen und drüben wieder 
unzippen.

MfG Paul

[Paul B. (paul_baumann)]

Ich weiß wirklich nicht, warum man meine Antwort 2x mit "nicht 
lesenswert"
markiert. Es ist doch FAKT, daß eine große Datei, die aus hunderten 
kleinen
durch zippen entstanden ist, sich wesentlich schneller übertragen läßt 
als
die hunderte Kleinen.

@Da Dieter
Wenn Du Dich auf mich eingeschossen haben solltest, dann teile mir das
mit. Ich würde Dir dann aus dem Wege gehen, wo es nur möglich ist.

Paul

[(prx) A. K. (prx)]

Paul Baumann schrieb:
> Alle Dateien mit Zip zusammenpacken, übertragen und drüben wieder
> unzippen.

Und wenn das am lokalen Platz scheitert, wie oben angedeutet: Man muss 
das nicht mit allen Files in einem Rutsch machen. Man kann das auch mit 
jeweils 1000 Files machen. Das ist näherungsweise gleich schnell, 
braucht aber kaum Platz lokal.

[Da D. (dieter)]

@Paul: Nein, nein, ich hab mich nich auf dich eingeschossen! Den 
Kommentar auf den du dich wahrscheinlich beziehst, hatte ich mal in 
einer frustrierten Minute geschrieben, als in einem Thread mal wieder 
überwiegend (zugegeben nicht nur von dir) Offtopic Beiträge auftauchten. 
Desswegen habe ich aber noch lange nix gegen dich und freue mich über 
fachliche Antworten, egal von wem sie kommen :-) Die negativen Bewertung 
hat wohl ein Leser abgegeben, da ich oben schrieb:

Da Dieter schrieb:
> Direktes Arbeiten auf dem Container, ohne lokale temp Dateien. Alle
> Daten lokal zusammen packen und dann rüber schieben geht leider aus
> Platzgründen nicht. Ansonsten hätte ich einfach ein Skript + ZIP
> genommen.

Zweifellos wäre ZIP und dann übertragen die schnellste Variante. Und 
die, die den Speicherplatz auf dem Netzwerkshare am besten ausnutzt. Das 
dumme ist nur, ich kopieren nicht ausschließlich kleine Dateien. So dass 
ich im worst case nicht genügend Speicherplatz für ein lokales ZIP 
Archive habe.

Im Moment sieht es wohl danach aus, dass ich einen dynamischen Container 
(wie die Microsoft Virtual HD) auf dem Netz ablege, und dann einfach 
damit leben muss, dass ich dort Speicher verschenke, wenn ich Dateien 
aus dem Container lösche.

[Da D. (dieter)]

A. K. schrieb:
> Und wenn das am lokalen Platz scheitert, wie oben angedeutet: Man muss
> das nicht mit allen Files in einem Rutsch machen. Man kann das auch mit
> jeweils 1000 Files machen. Das ist näherungsweise gleich schnell,
> braucht aber kaum Platz lokal.

Hm, ja das ist auch eine interessante Idee. Da muss ich mal ein bisschen 
Skriptbasteln und ausprobieren, wie gut das geht.