Изпечатай

[George Andonov]

Проблемът е следният:
Почти всички shell команди(ls, cp, mv, rm и т.н.) не работят, ако в една директория има повече файлове!

Пример с директория /dir, съдържаща около 4 000 файла:

Примерен код

user@host:/$ ls /dir/* bash: /bin/ls: Argument list too long

Решението, което съм намерил засега е:

Примерен код

user@host:/$ cd /dir user@host:/dir/$ ls * ... така работи

Но въпросът е докога ще работи?
Например при 10 000 файла ще работи ли?

Или с други думи:
Има ли ограничение за броят на файловете в една директория?
И ако има, как да го променя?

[rat]

Незнам за ограничение в боря на файловете, но според мен няма.
Ограничението идва броя на аргументите на дадена команда.
За да се решиш проблема може да направиш така :

Примерен код

find . | xargs rm -f

Така на командата rm ще се подава само по един аргумент.

[Hapkoc]

За ограничението на броя на файловете нямам идея, не съм проверявал, но командата 'ls /dir/*' не работи по следната причина - shell expansion. По-конкретно - обвивката 'разгъва' аргументите като * и ? и в резултата командата 'ls /dir/*' се преобразува в 'ls /dir/file1 /dir/file2 ...' и именно затова става твърде дълга.

С 'cd /dir && ls' не се получава проблема, мисля ясно защо. Така че ограничението за броя на файлове вероятно ще го срещнеш, когато не успееш да създадеш поредния файл в дадената директория.

Надявам се стана ясно какво се опитвам да кажа.

Веднъж имаш от coreutils (ls) - него си го забелязал. Това не е кой знае какво ограничение де..примерно можеш да направиш find /dir |xargs ls -l, ще свърши същата работа.

Втори път имаш и от файловата система. reiserfs подържа по принцип по-голям брой файлове в директория.

Въпреки че надали ще удариш лимита при ext2/3, тези файлови системи имат сериозни performance проблеми при opendir()/readdir() в директория с голям брой файлове - особено при положение че тези dentries не са кеширани от ядрото.

Някъде имаше една тема, където съветваха ако имаш дялове с много и малки файлове, да се използва reiserfs.

[George Andonov]

Благодаря на всички.
Засега модифицирах скрипта да работи с find.

Но фундаменталният въпрос който стой пред мен е:
Къде да съхранявам въпросните файлчета, след като ги обработя.
Всеки месец се генерират от 10 000 до 50 000 ТХТ файла с размер по 1к.
Засега ги разхвърлям по директории, но това е несериозно. А както се оказа и пълно с подмолни камъни. '>
Чудя се дали да ги слагам в SQL база? ...

С две думи: Какво мислите по въпроса?

Идеите ви ще бъдат високо оценени ... в халби '>

[rat]

Напиши си скрипт който да ги архивира във файл с име което да включва датата примерно. Така хем няма да ти заемат място хем ще ти е подредено.

[mhydra]

Цитат (Guest @ Юли 10 2006,14:41)

Въпреки че надали ще удариш лимита при ext2/3, тези файлови системи имат сериозни performance проблеми при opendir()/readdir() в директория с голям брой файлове - особено при положение че тези dentries не са кеширани от ядрото.

Наистина ехт2/3 може да имат спад в прооизводителността като всяка друга фс при високо количестово файлове в една директория, но това е нормално.
Бъди сигурен че 3,4,5 000 са нищо за тях. Не са сериозна пречка така че /бин/лс да не може да си свърши работата.
Ако си ползвал бонние++ ще ти направи впечатление че точно последните му няколкот теста са за работа с малки файлове. Създаване/ изтриване/ на малки по големина файлове. При мен в ехт3 и Федора Коре 5 броя създадени/изтрити  достига към 15 000. Така че 3,4 000 не са проблем за файловата система.
Проблемът го е обяснил Наркос. Просто командата не е построена правилно и по такъв начин задава неправилни аргументи. Това е всичко. Нищо и няма на ехт2/3.

[Hapkoc]

Цитат

Просто командата не е построена правилно и по такъв начин задава неправилни аргументи.

Не е съвсем така. Командата си е съвсем правилна и аргументите също, просто по този начин направено се сбъскваш с въпросното ограничение (а именно за дължина на команда).

Иначе rat е съвсем прав, най-читаво става с архивиране на файловете, още повече че текстовите файлове обикновено търпят силна компресия.

Всъщност като се зачетох и видях че при ext3 си имало htree. Това е организация на dentry-тата във вид на двоично дърво.

Какъв е смисълът ли? Едно е да обходиш един списък да речем с 5000 цикли докато достигнеш нужния запис, друго е това да отнеме 13 цикъла (2^13 = 8192, 4096<5000<8192)

Проблемът доколкото разбирам е че за това трябва да помислиш преди да си форматираш файловата система (mkfs.ext3 -O dir_index)

А иначе 4-5 хиляди файла в директория не са проблем вероятно за никоя файлова система. Въпросът е че ext2/ext3 са пословично бавни при такива големи директории. ReiserFS адресира точно този проблем, но радостно е че и ext3 все пак има възможност за решението му. Между другото и при reiserfs нещата се реализират с дървета, но доколкото знам не са двоични. На Ханс Райзер теориите са прекалено затормозяващи за четене, нека големите глави да си блъскат главата с тях '>