[Linux]Behandel meerdere bestanden als één bestand

[Verwijderd]

Tweaker-mensen,

Om maar even met de deur in huis te vallen:
Wij werken regelmatig met opgesplitste images van harde schijven. Doorgaans zijn die losse bestanden 1GB.
Dus maken we een image van een harddisk van 20GB, dan levert ons dat 20 bestanden op. (in oplopende volgorde voor wat betreft de bestandsnaam)

Mijn vraag is:
Kan iemand mij helpen aan een tool of een oplossing die ervoor zorgt dat ik images samen weer kan zien als zijnde één file, zonder dat ik ze werkelijk weer moet samenvoegen met zoiets als 'cat * > eenfile.img' of join?

[mithras]

Waarmee maak je de images? Dd kan je pipen naar split. Dan kan je vervolgens die splits weer met cat aan elkaar plakken.

/edit: dus [google=dd+split] en daarna [google=split+cat]
Sorry, ik lees 99% van de post. Na mijn post lees ik de resterende 1% Maar dan de vraag: waarom geen cat? Alleen omdat je dan een enorme file krijgt waar je niet goed mee overweg kan?

[ Voor 54% gewijzigd door mithras op 31-08-2009 12:10 ]

[aequitas]

Wilde gok, weet niet of dat ga werken. Maar probeer met software raid een md device aan te maken van de disk images als stripe of concat. Weet niet of hier nog veel extra meta data voor nodig is op het filesysteem en dat je daar dus je images voor moet aanpassen.

Kan je ook aangeven waarom je de image als geheel moet zien zonder dat je ze samen kan voegen. Dan kunnen we misschien het probleem beter begrijpen.

[Verwijderd]

Gewoon cat 1.img 2.img 3.img > final.img. Werkt prima hoor

[Verwijderd]

Hoewel het misschien wat off-topic is, ga ik het even uitleggen. Dat van dat niet catten:
We hebben namelijk nogal veel van die images

En dat gaat dan resulteren in óf alle images van schijven 2x (1x losse kleine files, 1x 1 grote image) En dat kost een hoop ruimte (op niets af). Óf we hebben de nadelen van bijvoorbeeld losse kleine files, of één grote.

Nou, dan kunnen we hier beter een permanente oplossing voor vinden waar we juist alleen de voordelen hebben. Vandaar dus mijn vraag!

[Pim.]

en titlefix

[Verwijderd]

Pim. schreef op maandag 31 augustus 2009 @ 12:22:
en titlefix

Dank

[grizzlybear]

Misschien heb je hier iets aan:

File::LinearRaid - Treat multiple files as one large seamless file for reading and writing.

http://search.cpan.org/~r...12/lib/File/LinearRaid.pm

[Sendy]

En anders kan je met FUSE je eigen filesysteem schrijven die dit voor je doet.

Maar waar het eigenlijk om gaat is: hoe ga je die (samengestelde) files gebruiken? Je schrijft dat je de files wil "zien" als een (1) grote file, maar is dat zien met grep, met dd, met een ftp client?

[leuk_he]

Hoe ga je de files gebruiken? Weer als filesysteem mounten onder linux? Lukt het echt die als grote files te handlen?

LVM (lijkt wat op raid) is uiteraard pas een oplossing als je de images vanaf het begin maakt m.b.v. zo'n oplossing.

[Verwijderd]

Op de vraag "waar ik het voor wil gebruiken" heb ik simpel gezegd het volgende 'nietszeggende' antwoord:
Alle tools die mij op dat moment maar aanstaan!

Nu komt dat nu neer op bijvoorbeeld PhotoRec, maar een andere keer kan dat grep zijn inderdaad. En misschien dat ik in de toekomst wel weer iets anders wil. Uiteraard kun je met zoiets als grep door meerdere files zoeken, maar dan zit je bijvoorbeeld weer met je fileoffset. Allemaal overkomelijk, maar lang niet zo handig als dat het één file zou wezen.

Vandaar dus nu de stoute schoenen aangetrokken voor 'de alles-omvattende oplossing'

Ik ben zelf ook op LinairRead van CPAN uitgekomen, en ik denk dat ik die mijns inziens zo handige functionaliteit dan toch maar zelf in elkaar ga zitten beuken. Houdt me weer van de straat....

[Sendy]

Grep is natuurlijk makkelijk (cat file1 file2 | grep), maar de meeste andere programma's zijn moeilijk. De enige niet-Perl oplossing is in mijn ogen dan met FUSE een eigen filesystem schrijven.

[Elijan9]

Hoe maak je de diskimages en hoe wil je ze weer bekijken? Want misschien moet je overwegen het formaat waarin je ze opslaat anders te kiezen.

Als je bijvoorbeeld partedimage gebruikt, dan kan deze automatisch HD images splitsen bij het creëren en weergeven als geheel bij het inlezen. Maar ook bijvoorbeeld de disks die virtualisatie omgevingen gebruiken, worden standaard in chunks opgedeeld. Misschien is dat een handig formaat? Of gewoon multi-volume archives, RAR kan dit, maar dit zal vast niet de enige zijn.

Ergens denk ik dat elke disk-imager dat toch wel zou moeten kunnen. Of wil jij het image kunnen mounten als image? Volgens mij moet het heel eenvoudig zijn zoiets op basis van FUSE te schrijven met bijvoorbeeld Python. Eenvoudig zolang je er niet naar wilt schrijven in elk geval... Met genoeg tijd zou ik het kunnen.

[Verwijderd]

De images maak ik normaliter 'gewoon' met dd en split. Maar ik wil ook met bijvoorbeeld gesplitste vmware-images kunnen werken. En mogelijk nog wel meer gangbare/voorkomende formaten...

[sam.vimes]

Verwijderd schreef op maandag 31 augustus 2009 @ 12:18:
Hoewel het misschien wat off-topic is, ga ik het even uitleggen. Dat van dat niet catten:
We hebben namelijk nogal veel van die images

En dat gaat dan resulteren in óf alle images van schijven 2x (1x losse kleine files, 1x 1 grote image) En dat kost een hoop ruimte (op niets af). Óf we hebben de nadelen van bijvoorbeeld losse kleine files, of één grote.

Nou, dan kunnen we hier beter een permanente oplossing voor vinden waar we juist alleen de voordelen hebben. Vandaar dus mijn vraag!

Je kunt toch eenvoudig een scriptje schrijven dat voor alle images het volledige image samenstelt uit de losse delen en direct daarna (voordat je aan het volgende image begint) de losse delen weggooit.
Dan heb je slechts de grootte van één image als werkruimte nodig. Of snap ik het verkeerd?

[Verwijderd]

Ja, no offense, maar ik denk dat je me verkeerd begrijpt.
Ik wil namelijk geen enkele image weggooien!

[odysseus]

Is het een optie om het probleem aan de andere kant aan te pakken? Je splitst de images nu, maar is daar een dwingende reden voor? Je hebt blijkbaar genoeg opslagruimte om de gesplitste images op te slaan, dus zou je ook genoeg moeten hebben om het ongesplitste bestand te bewaren. Als het splitsen gebeurt omdat de schijven waarop de boel opgeslagen wordt te klein zijn, zou je met LVM wel iets kunnen doen - en als er een andere reden is dat het op dit moment gesplitst opgeslagen wordt, dan kan daar misschien ook wel omheen worden gewerkt .

Mocht dat niet kunnen, dan is het gebruik van FUSE waarschijnlijk de simpelste optie - zo lang je niet naar je image wilt schrijven is het triviaal om de offset voor het lezen uit een willekeurig bestand uit te rekenen .

[smokalot]

TS doet dit vermoedelijk vanwege filesystem-beperkingen? Fat32 heeft maar een 4GB limiet...

OS X heeft hier hele handige sparse bundles voor, een automatisch groeiende image, die zich splitst over meerdere bestanden als ie groeit. Voor linux bestaat dit niet, maar moet niet heel lastig zijn om met FUSE te schrijven. Voordat je een beetje snelle, bugvrije implementatie hebt geschreven kun je wel zo een paar dagen bezig zijn, afhankelijk van je programmeerskillz.

Ik ben er laatst wel achter gekomen hoe je een sparse image maakt onder linux, een bestand wat groter is dan de ruimte die ie inneemt, en groeit naar behoefte:

code:

dd if=/dev/zero of=sparse-file bs=1 count=0 seek=50G

creeert een bestand waar 50gig in kan, maar initieel slechts een paar bytes inneemt. Ik weet niet of je daar iets aan hebt.

[Verwijderd]

Filesystembeperkingen is inderdaad de beweegreden van de TS
Ik/Wij hebben ruimte genoeg.... Het gaat erom dat ik/wij niet van tevoren weten aan wie we de images moeten uitleveren/afleveren

[DJ Buzzz]

Dan zou ik iets bouwen waarbij je bij het uitleveren van images ze past splitst. Zo werk je er zelf altijd mee als hele bestanden en alleen als ze op een FAT32 o.i.d. uitgeleverd moeten worden splits je ze. Lijkt me stuk handiger dan er intern de hele tijd mee te moeten goochelen .

[Verwijderd]

Ja, dat zou ook handig zijn.... Echter, ik heb dit niet altijd (alleen) in de hand.
We kunnen het spul ook aangeleverd krijgen...
Het kunnen vmware images zijn bijvoorbeeld. Of een nu nog niet voorzien gesplitst formaat. (noem maar een voorbeeld: Ghost ofzo... En zo valt er nog wel iets te bedenken als je er even voor gaat zitten)

Bottomline is dat ik een 'truc' wil om gesplitste bestanden te kunnen behandelen als zijnde één bestand. Ik denk dat ik anders de topic wel was gestart met: Wie weet hoe ik bestanden kan opsplitsen nadat ik zelf heerlijk heb gewerkt met één hele grote!

[smokalot]

Een fuse fs zou er ongeveer zo uit moeten zien:
het programma krijgt een lijst bestanden mee (via configuratiebestandje of op de cmdline), en exporteert een groot bestand. Dat grote bestand kun je dan met mount -o loop /pad/naar/bestand /mountpoint mounten.

Het fuse programmaatje hoeft alleen maar de positie van de gevraagde positie te vertalen naar de juiste positie in het grote bestand. Omdat het programmaatje op zich niet zoveel doet moet de performance nog steeds fatsoenlijk zijn.