`cat veel files > partitie` ==> Argument list too long

[RemcoDelft]

Situatie
ik heb meerdere images van een encrypted partitie (gemaakt met `cat /dev/sda > image`). Deze heb ik met `split` in een half miljoen stukjes gehakt, zodra ik onveranderde data kan hardlinken om ruimte te besparen.
Ik heb dit vaker gedaan, maar dan met minder files. De backup terugzetten kan dan eenvoudig met `cat * > /dev/sda`. De reden dat ik het zo doe is dat het zo eenvoudig intuitief werkt.

Probleem
Met zo veel files loop ik tegen de limiet van expansie van * aan, wat resulteert in de melding "Argument list too long". Ik heb het idee dat de limiet op het aantal files een overblijfsel is uit de tijd dat je een paar MB ram had, terwijl die limiet allang verhoogd had kunnen worden.

Workaround
Ik kan deelselecties maken, die naar een file `cat`ten, en vervolgens de grotere files naar de harddisk `cat`ten. Dat werkt, maar maakt dat het het restore-proces drie keer zo lang duurt en flink veel diskruimte nodig heeft.
Als ik de kleine files naar een grote file schrijf, kan ik ook gewoon "aan het eind" van de file verdergaan met toevoegen, waardoor het geen probleem is om het niet vanuit 1 `cat` commando te doen. Naar een partitie werkt dat niet.
Google geeft diverse oplossingen met een `find`-constructie, maar die gaan uit van schrijven naar een filesystem.

Gewenst
Een constructie die hier wel mee kan omgaan. Voorlopig heeft het geen haast, backup is al teruggezet, maar voor de toekomst heb ik graag een systeem wat beter werkt dan dit.

[Hero of Time]

Als je iets wilt dat beter werkt, moet je ook echt iets gebruiken wat ervoor gemaakt is. Nu doe je iets heel simpels en verwacht je er geavanceerde resultaten van. Het is ook nooit bedoelt om zoiets te doen.

Je kan beter nadenken over wat je nou precies hiermee wilt doen en hoe je dat dan gaat uitvoeren, dan deze half bakken 'oplossing' proberen te laten werken. Bijvoorbeeld een encrypted container maken en die via rsync backuppen.

[RemcoDelft]

Hero of Time schreef op zondag 07 juni 2015 @ 11:22:
Als je iets wilt dat beter werkt, moet je ook echt iets gebruiken wat ervoor gemaakt is. Nu doe je iets heel simpels en verwacht je er geavanceerde resultaten van. Het is ook nooit bedoelt om zoiets te doen.

Ik hoop(te) er mee weg te komen dat niet te doen.

Je kan beter nadenken over wat je nou precies hiermee wilt doen en hoe je dat dan gaat uitvoeren, dan deze half bakken 'oplossing' proberen te laten werken. Bijvoorbeeld een encrypted container maken en die via rsync backuppen.

De originele partitie is al encrypted, en betreft een zakelijke laptop dus daar aanpassingen maken is geen optie. De backup hoeft dan ook niet opnieuw te worden encrypted.

[Slurpgeit]

Even los van het feit dat het uiteraard een keer onherroepelijk mis gaat met deze methode, werkt iets als dit niet (niet getest)?

for i in $(ls); do cat $i >> /dev/sda; done

Anders even snel iets met python in elkaar klussen?

[RemcoDelft]

Ik heb `>> /dev/sda` nooit getest, maar ga er vanuit dat dat niet werkt.

[Hero of Time]

Dat zal idd zeer waarschijnlijk niet werken, want >> wil zeggen 'append' en je kan niet aan een partitie appenden. Al zou dat wel werken, dan krijg je corrupte data, omdat je aan het eind van de partitie/schijf gaat schrijven en dat kan nooit goed gaan.

RemcoDelft schreef op zondag 07 juni 2015 @ 11:26:
[...]

Ik hoop(te) er mee weg te komen dat niet te doen.

Dat willen er zo veel, maar je ontkomt er niet aan.

[...]

De originele partitie is al encrypted, en betreft een zakelijke laptop dus daar aanpassingen maken is geen optie. De backup hoeft dan ook niet opnieuw te worden encrypted.

Je backup is dan de encrypted container zelf, wat je nu ook al hebt maar dan in duizenden kleine bestanden. Rsync doet alleen de wijzigingen overnemen, dus als bij offset 500MB iets is verandert, wordt alleen dat deel overgenomen, zoals je nu ook al hebt.

Maar als je zegt dat je backup niet eens encrypted hoeft te zijn, waarom doe je dan zo enorm moeilijk? Maak dan gewoon een backup van de bestanden via de vele bestaande tools. Copy/paste het desnoods.

[RemcoDelft]

Hero of Time schreef op zondag 07 juni 2015 @ 12:08:
Je backup is dan de encrypted container zelf, wat je nu ook al hebt maar dan in duizenden kleine bestanden. Rsync doet alleen de wijzigingen overnemen, dus als bij offset 500MB iets is verandert, wordt alleen dat deel overgenomen, zoals je nu ook al hebt.

Maar dit bespaard toch alleen dataverkeer, dus ideaal voor remote backups? Voor zover ik weet is dit niet geschikt om diskruimte te besparen bij meerdere backups.

Maar als je zegt dat je backup niet eens encrypted hoeft te zijn, waarom doe je dan zo enorm moeilijk? Maak dan gewoon een backup van de bestanden via de vele bestaande tools. Copy/paste het desnoods.

De backup hoeft niet encrypted te zijn, omdat het origineel dat al is. Als ik losse files ga kopieren is het een ander verhaal. Maar dan nog lost het geen corrupt Windows-register op (zoals nu het geval was).

[CyBeR]

Slurpgeit schreef op zondag 07 juni 2015 @ 11:34:
Even los van het feit dat het uiteraard een keer onherroepelijk mis gaat met deze methode, werkt iets als dit niet (niet getest)?

for i in $(ls); do cat $i >> /dev/sda; done

Dat moet je sowieso nooit doen.


http://mywiki.wooledge.org/ParsingLs

[Hero of Time]

RemcoDelft schreef op zondag 07 juni 2015 @ 12:18:
[...]

Maar dit bespaard toch alleen dataverkeer, dus ideaal voor remote backups? Voor zover ik weet is dit niet geschikt om diskruimte te besparen bij meerdere backups.


[...]

De backup hoeft niet encrypted te zijn, omdat het origineel dat al is. Als ik losse files ga kopieren is het een ander verhaal. Maar dan nog lost het geen corrupt Windows-register op (zoals nu het geval was).

Tja, zoals ik al zei, gebruik een tool dat hiervoor is gemaakt en ga niet met dingen werken die hier nooit voor bedoelt zijn. Er zijn genoeg oplossingen om een backup te encrypten, inclusief incrementals.

[RemcoDelft]

Hero of Time schreef op zondag 07 juni 2015 @ 13:12:
... en ga niet met dingen werken die hier nooit voor bedoelt zijn.

Hier ben ik het niet mee eens. Het is juist allemaal bedoeld om op zo veel mogelijk manieren te kunnen worden gebruikt. Vandaar dat een partitie gewoon als file te benaderen is, en vandaar dat "cat partitie > file" en andersom gewoon werkt. De enige limiet zit in het aantal kleine files wat ik er van gemaakt heb.

[Kees]

(find . -type f - exec cat {} \;) > /dev/sda

[deadinspace]

RemcoDelft schreef op zondag 07 juni 2015 @ 11:10:
Situatie
Met zo veel files loop ik tegen de limiet van expansie van * aan, wat resulteert in de melding "Argument list too long". Ik heb het idee dat de limiet op het aantal files een overblijfsel is uit de tijd dat je een paar MB ram had, terwijl die limiet allang verhoogd had kunnen worden.

Dat valt tegen vrees ik; het is een limiet van de Linux kernel (en elke andere Unix kernel), en de Linux kernel mensen zijn niet happig op arbitraire limieten. Bovendien zijn deze beperkingen op de meeste OSsen door de tijd heen verhoogd, wat suggereert dat ze zich wel degelijk bewust zijn van de nadelen ervan, maar dat die limiet toch noodzakelijk is.

Ik heb de exacte rationale achter die beperking niet gevonden, maar het zou me niks verbazen als het een DoS-bescherming is, omdat bij grote argumentlijsten de kernel veel geheugen moet kopieren bij een execve(). Maargoed, dat is grotendeels een gok.

Gewenst
Een constructie die hier wel mee kan omgaan. Voorlopig heeft het geen haast, backup is al teruggezet, maar voor de toekomst heb ik graag een systeem wat beter werkt dan dit.

find -type f -print0 | sort -zn | xargs -0 cat | pv -s8G > /dev/partitie

(voor een partitie van 8GB)
De pv is optioneel maar handig. De sort is niet optioneel, want de volgorde van je stukjes is best belangrijk.

[CAPSLOCK2000]

xargs

Deadinspace noemt het al in zijn antwoord maar ik weet niet of je doorhebt dat dit de kern van het antwoord op je vraag is.

Los van de discussie of jouw toepassing nu handig of verstandig is kun je xargs gebruiken om met situaties om te gaan waarin je meer files wil gebruiken van lukt met een simpele *. Vaak wordt het dan gecominbeerd met find om de lijst met files te maken.

Lees vooral even de man-page van xargs want het heeft enorm veel handige opties om met allerlei situaties om te gaan.

[noMSforme]

Hoe groot zijn de stukjes die je nu maakt met split ?
Kun je niet gewoon grotere 'stukjes' maken. Bijv: 2 Mb ipv 1 Mb ?

[RemcoDelft]

Deze twee zien er veelbevolgend uit:

Kees schreef op zondag 07 juni 2015 @ 13:27:
(find . -type f - exec cat {} \;) > /dev/sda

Edit: als ik doe:
find directory -type f -exec ls {} \;)
Staan de files in willekeurige volgorde (terwijl cat * netjes alfabetisch is).

deadinspace schreef op zondag 07 juni 2015 @ 17:07:

find -type f -print0 | sort -zn | xargs -0 cat | pv -s8G > /dev/partitie

Bedankt! Testen zit er momenteel even niet in, zodra dat gelukt is laat ik het hier weten.
Edit: Een aangepaste versie hiervan werkt prima om de files allemaal te vergelijken. Resultaat na 1 maand: 90 GB is veranderd, 380 GB is onveranderd. Een flinke ruimtebesparing dus.

noMSforme schreef op zondag 07 juni 2015 @ 18:42:
Hoe groot zijn de stukjes die je nu maakt met split ?
Kun je niet gewoon grotere 'stukjes' maken. Bijv: 2 Mb ipv 1 Mb ?

Het is nu 1 MB. Voor het doel zou ik ze juist kleiner willen hebben, anders zouden ze 20 MB moeten worden.

[ Voor 16% gewijzigd door RemcoDelft op 10-06-2015 18:21 ]

[Slurpgeit]

CyBeR schreef op zondag 07 juni 2015 @ 13:06:
[...]


Dat moet je sowieso nooit doen.


http://mywiki.wooledge.org/ParsingLs

Je moet sowieso eigenlijk niet doen waar de TS om vraagt. De redenen die jij linkt zijn hier echter niet van toepassing omdat je precies weet (en kan beinvloeden) wat de filenames in de map zijn. ">>" gaat natuurlijk niet werken bedenk ik me nu.

Je zou ook in python zoiets kunnen doen:

Python:

#!/usr/bin/env python

import os

def listfiles(path):
    files = sorted(os.listdir(path), key=str.lower)
    return files

def writedisk(disk, files):
    with open(disk,'wb') as d:
        for file in files:
            with open(file,'rb') as f:
                d.write(f.read())
                f.close()
    d.close()

def main():
    path = '/backup'
    disk = '/dev/sda'
    files = listfiles(path=path)
    writedisk(disk=disk, files=files)

if __name__ == '__main__':
    main()

Ervan uitgaand dat de files op alfabetische volgorde staan.

[CyBeR]

Slurpgeit schreef op maandag 08 juni 2015 @ 17:30:
[...]


Je moet sowieso eigenlijk niet doen waar de TS om vraagt. De redenen die jij linkt zijn hier echter niet van toepassing omdat je precies weet (en kan beinvloeden) wat de filenames in de map zijn.

Totdat iemand er een file tussen weet te stoppen natuurlijk.

[H!GHGuY]

Kees schreef op zondag 07 juni 2015 @ 13:27:
(find . -type f - exec cat {} \;) > /dev/sda

Performance-wise wil je dit niet doen. Het is namelijk 1 invocatie van cat per file...
De oplossing van deadinspace heeft dan toch wel het voordeel.

[Kees]

H!GHGuY schreef op maandag 08 juni 2015 @ 18:34:
[...]


Performance-wise wil je dit niet doen. Het is namelijk 1 invocatie van cat per file...
De oplossing van deadinspace heeft dan toch wel het voordeel.

Performance heeft dit topic al weinig mee te maken

[deadinspace]

RemcoDelft schreef op zondag 07 juni 2015 @ 12:18:
Maar dit bespaard toch alleen dataverkeer, dus ideaal voor remote backups? Voor zover ik weet is dit niet geschikt om diskruimte te besparen bij meerdere backups.

Nee, rsync kan ook hardlinks gebruiken voor onveranderd bestanden, waarmee je tussen de verschillende snapshots vrij veel ruimte kunt besparen.

Als ik losse files ga kopieren is het een ander verhaal. Maar dan nog lost het geen corrupt Windows-register op (zoals nu het geval was).

De Windows registry is toch ook gewoon een file (of aantal files)?

Slurpgeit schreef op maandag 08 juni 2015 @ 17:30:
Je moet sowieso eigenlijk niet doen waar de TS om vraagt.

Dat hebben nou al een paar mensen hier gezegd, maar... Waarom niet eigenlijk?

Ik kan wel redenen bedenken tegen zijn aanpak, maar ook voor zijn aanpak. Ik ben er eigenlijk helemaal niet van overtuigd dat het zo'n slechte manier is.

Kees schreef op maandag 08 juni 2015 @ 18:39:
Performance heeft dit topic al weinig mee te maken

Hoezo dat niet?

[RemcoDelft]

CyBeR schreef op maandag 08 juni 2015 @ 18:23:
Totdat iemand er een file tussen weet te stoppen natuurlijk.

Als iemand toegang tot je backups heeft heb je hele andere problemen.

deadinspace schreef op maandag 08 juni 2015 @ 19:04:
Nee, rsync kan ook hardlinks gebruiken voor onveranderd bestanden, waarmee je tussen de verschillende snapshots vrij veel ruimte kunt besparen.

Dat gebruik ik op zich ook al (elders, zeg maar TimeMachine backups), maar gaat niet helpen voor een kopie van een hele partitie.

Ik kan wel redenen bedenken tegen zijn aanpak, maar ook voor zijn aanpak. Ik ben er eigenlijk helemaal niet van overtuigd dat het zo'n slechte manier is.

Het is een methode die ik al 20 jaar (af en toe) gebruik (voor floppy disks, CDroms, hele harde schijven of slechts (encrypted) partities, SSD, CF, SD, etc), en het werkt altijd goed ongeacht het filesystem wat er op staat. Er zijn vast en zeker "betere" manieren, die dan over 3 jaar weer vervangen worden door iets "beters". Groot voordeel van deze methode is dat het gewoon altijd werkt en over 20 jaar nog steeds werkt en beschikbaar is.

Kees schreef op maandag 08 juni 2015 @ 18:39:
Performance heeft dit topic al weinig mee te maken

Performance is niet zo relevant, gezien de USB3-poort de beperking is. En het komt niet op een paar minuten.

[ Voor 6% gewijzigd door RemcoDelft op 08-06-2015 20:14 ]

[deadinspace]

RemcoDelft schreef op maandag 08 juni 2015 @ 20:10:
Dat gebruik ik op zich ook al (elders, zeg maar TimeMachine backups), maar gaat niet helpen voor een kopie van een hele partitie.

Ahzo, ik las dat stukje in de context van "filesystem backuppen naar een encrypted container", maar het kan zijn dat ik verkeerd gelezen heb

[JeroenE]

/bin/sh -c "cat ~/splitdir/* > /dev/sdb"

Maar wellicht is dat ook nog afhankelijk van je /bin/sh. Ik heb niet allerlei shell-varianten getest.

[deadinspace]

JeroenE schreef op maandag 13 juli 2015 @ 19:10:

/bin/sh -c "cat ~/splitdir/* > /dev/sdb"

Dat gaat niet helpen; je roept nog steeds "cat" aan met teveel argumenten, wat dus nog steeds mis gaat. De oplossing hiervoor is xargs.

Maar wellicht is dat ook nog afhankelijk van je /bin/sh. Ik heb niet allerlei shell-varianten getest.

Het is niet afhankelijk van je shell, het is een OS-beperking in de hoeveelheid argumenten die je mee kunt geven bij de uitvoer van een programma.

[Ventieldopje]

Slurpgeit schreef op zondag 07 juni 2015 @ 11:34:
Even los van het feit dat het uiteraard een keer onherroepelijk mis gaat met deze methode, werkt iets als dit niet (niet getest)?

for i in $(ls); do cat $i >> /dev/sda; done

Anders even snel iets met python in elkaar klussen?

Waarom niet eerst concatten naar een "image" en die dd'en (of via cat whatever) naar /dev/sda?

[MartinMeijerink]

Zo gaat het goed:

ls -1|while read;do cat "$REPLY";done>/dev/sda