---

Hej NG'ere

Ligger der nogen begrænsning i antal filer et unix-system (AIX 4.3) kan
håndtere.

Jeg kan fx ikke bruge mv *.gz fra et bibliotek med omkring 2800 filer,
hvoraf ca. 1600 er gz-filer. Så går jeg bare
ksh: /usr/bin/mv: 0403-027 The parameter list is too long.

Kan jeg også risikere at få problemer med at tilgå de enkelte filer hvis der
for alvor bliver for mange?

Hilsen Troels Lind

---

Troels Lind skrev:
> Hej NG'ere
>
> Ligger der nogen begrænsning i antal filer et unix-system (AIX 4.3) kan
> håndtere.
>
> Jeg kan fx ikke bruge mv *.gz fra et bibliotek med omkring 2800 filer,
> hvoraf ca. 1600 er gz-filer. Så går jeg bare
> ksh: /usr/bin/mv: 0403-027 The parameter list is too long.
>

Problemet ligger ikke i filsystemet men hvor lang en kommandolinie maa
vaere i det paagaeldende system. Naar du skriver

   mv *.gz /tmp

så ekspanderes *.gz til alle de filnavne der findes, og resultatet
sendes videre til "mv", som ikke ser "*.gz".

Det er her at kæden knækker. Standardløsningen er at bruge xargs til at
dele kommandoen op, men jeg kan ikke lige komme på en passende
anvendelse i dit tilfælde :)

Har du mulighed for at installere "mc"? Dens brugerflade er ok, og kan
godt håndtere så mange filer.

--
Thorbjørn
   

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

>    mv *.gz /tmp

> Det er her at kæden knækker. Standardløsningen er at bruge xargs til
> at dele kommandoen op, men jeg kan ikke lige komme på en passende
> anvendelse i dit tilfælde :)

Med GNU-mv kam man lave en:

find -maxdepth 1 -name \*.gz | xargs mv --target-dir /tmp

Uden GNU-mv er man tvunget til at enten bruge -exec med find elelr se
om ens xargs har en option svarende til -i i GNU-xargs (tilsyneladnede
-J på FreeBSD).

find -maxdepth 1 -name \*.gz -exec mv {} /tmp \;
find -maxdepth 1 -name \*.gz | xargs -i mv {} /tmp

--
Peter Makholm | Emacs is the only modern general-purpose
peter@makholm.net | operating system that doesn't multitask
http://hacking.dk |

---

"Troels Lind" <lind@e-box.dk> writes:

> Ligger der nogen begrænsning i antal filer et unix-system (AIX 4.3) kan
> håndtere.

Jeg tror ikke at der er nogen grænse, ud over den begrænsning der
ligger i størelsen af mulige filer (kataloger er bare specielle
filer).

Der er en grænse for hvor effektivt man kan behandle filerne. På Linux
med ext2 laver den vist nok en liniær søgning gennem kataloget når den
skal finde et bestemt filnavn. Det giver altså en køretid på O(n) på
mange filer.

Selv hvis kernen kan håndterer mange filer effektivt (hashing af
filnavne, søgetrærer, whatever), så er der mange steder hvor
user-space programmer laver en

opendir(DIR, $some_dir) || die "can't opendir $some_dir: $!";
@dots = grep { /^\./ && -f "$some_dir/$_" } readdir(DIR);
closedir DIR;

Hvilket giver liniær køretid uanset hvor smart selve filsystemet er.

--
Peter Makholm | Ladies and gentlemen, take my advice, pull down your
peter@makholm.net | pants and slide on the ice
http://hacking.dk | -- Sidney Freedman

---

Peter Makholm skrev:
>
> Selv hvis kernen kan håndterer mange filer effektivt (hashing af
> filnavne, søgetrærer, whatever), så er der mange steder hvor
> user-space programmer laver en
>
> opendir(DIR, $some_dir) || die "can't opendir $some_dir: $!";
> @dots = grep { /^\./ && -f "$some_dir/$_" } readdir(DIR);
> closedir DIR;
>
> Hvilket giver liniær køretid uanset hvor smart selve filsystemet er.

Hvis du skal behandle alle filerne er du da noedsaget til at have linear
koeretid.

Fordelen ved heksekunstnerne er jo hvis du bare skal bruge een fil og
skal bruge den nu.

Til Unix er der ioevrigt en fast oevre graense for et filsystem
afhaengig af hvor mange inodes der er sat til side dengang partitionen
blev formatteret. Det kan fsck vistnok orientere om.

--
Thorbjoern

---

Thorbjoern Ravn Andersen <thunderbear@bigfoot.com> writes:

> Hvis du skal behandle alle filerne er du da noedsaget til at have
> linear koeretid.

Korrekt. Ovenstående kunne iøvrigt godt nå op på noget der ligner
O(n^2) da -f laver en stat som også tager O(n)-tid.

> Til Unix er der ioevrigt en fast oevre graense for et filsystem
> afhaengig af hvor mange inodes der er sat til side dengang partitionen
> blev formatteret. Det kan fsck vistnok orientere om.

'df -i'

--
Peter Makholm | First you fall in love with Antarctica, and then it
peter@makholm.net | breaks you heart
http://hacking.dk | -- Antarctica

---

In article <y8aX8.8$922.703@news.get2net.dk>,
"Troels Lind" <lind@e-box.dk> wrote:

> Hej NG'ere
>
> Ligger der nogen begrænsning i antal filer et unix-system (AIX 4.3) kan
> håndtere.
>
> Jeg kan fx ikke bruge mv *.gz fra et bibliotek med omkring 2800 filer,
> hvoraf ca. 1600 er gz-filer. Så går jeg bare
> ksh: /usr/bin/mv: 0403-027 The parameter list is too long.
>
> Kan jeg også risikere at få problemer med at tilgå de enkelte filer hvis der
> for alvor bliver for mange?

Dit problem er, at *.gz expanderes, og din kommandolinie bliver længere
end den må være. Anvend i stedet

find . -name "*.gz" -exec mv {} anotherdir \;

den er lidt langsom.

I andre tilfælde kan man bruge xargs:

find . -name "*.gz" | xargs chown root.root

Her kaldes kommandoen efter xargs med så mange parametre som mulig uden
at linien bliver for lang

Antal åbne filer pr. bruger er en parameter du kan fedte i med smit /
smitty