zuborg

Вполне может быть что эту ошибку генерирует апач, проверьте post_max_size в php.ini, и error логи nginx-а и апача, также сравните access-логи для Вашего запроса в nginx-е и апаче

Не примите за занудство, но bash (и другие sh) не умеет заходить на ftp. Вам необходимо использовать внешнюю программу, которая это умеет, и тут начинаются зависимости от версии Вашей ОС, что установлено и что можно установить и т.д. и т.п. Уточните вопрос.

btw, если есть возможность логина по ssh вместо ftp, то вопрос решается легко через
find /path/to/dir -type f | wc -l
Всяко производительней делать подсчет на стороне где лежат эти файлы, вместо пересылки списка файлов. Кроме того, команда dir протокола ftp не делает рекурсивный листинг, так что таких команд придется прогнать столько, сколько найдется поддиректорий, это дополнительные тормоза.

Дробить надо, причин тому много, фактически все сводится к тому, что чем больше обьектов в папке — тем больше ресурсов надо на их поиск (и другие операции). В некоторых случаях — пропорционально размеру…
Найти файл (или пустое место для создания нового) среди миллиона таких же в папке сложнее, чем сначала найти его подпапку среди тысячи подпапок, и потом найти нужный файл среди тысячи в выбранной подпапке. Даже с техниками индексирования содержимого папок…

Итого, желательно чтобы максимальное кол-во обьектов в папке было порядка 1к-5к. Добавлять односимвольные подпапки, к примеру, не эффективно — их получится много и кол-во операций поиска елемента в папке сильно увеличится (хотя операции эти будут сравнительно простыми). Идеально — 3 (максимум 4) цифры на подпапку, либо 2 символа включая буквы (для равномерной плотности распределения символов в имени).

Размер потерь на место — это приблизительно 1/2 * размер блока (для некоторых FS — фрагмента блока, как в UFS) * кол-во файлов (+папок) + оверхед FS * кол-во блоков.
Исходя из первого слагаемого — блоки надо делать как можно меньше, а из второго — как можно больше (тогда блоков будет меньше).
Первое слагаемое можно оценить непосредственно (`df -i` в помощь), второе — оценить, сравнив полное место согласно выводу команды df с собствено размером диска (раздела), обычно разница порядка несколько процентов. В идеале оба слагаемых должны быть приблизительно равны.

1. используйте verbose режим в ssh, например коннектесь с unix-сервера или с самой убунты на себя же (залогинившись как slave):
# ssh -v master@1.2.3.4
2. смотрите логи в /var/log/ особенно auth.log, security.log, messages.log
3. просмотрите содержимое ~master/.ssh/ возможно там кроме ключей какие-то нестандартные конфиги или rc-скрипты.
4. просмотрите /etc/ssh/, возможно что-то обнаружите в sshd_config или возможно там есть sshrc скрипт

Так обьектный файл как раз машинный код и содержит, и его размер таки меньше получился.

Надо смотреть на опции сборки, активирован ли дебаг режим, сделан ли strip…

Касательно фри — ядро 8 изменилось относительно 7-ки весьма и весьма, в целом в лучшую сторону, но есть некоторые моменты в сетевой части которые ухудшились. Инфу думаю можно считать не актуальной — фря 9-ка на подходе, надо тестить все заново ;)