Привет, ЛОР!

Есть бездисковая система на основе Debian Squeeze. Корневой раздел на nfs. Была проблема: при выключении, после вызова halt, система зависала пытаясь связаться с nfs-сервером. При этом выдавалось сообщение вроде:

nfs: server ... not responding, still trying

-d -f -i -p -h

Привет ЛОР!

Пытаюсь сделать образ бездисковой системы на основе Debian Squeeze. Предполагается, что образ будет распаковываться на произвольный linux-based сервер (от RedHat 6 до OpenSuse 11.4), директория содержащая распакованные файлы будет экспортироваться по NFS. Далее клиент стандартным образом грузится через PXE и получает в качестве корневого раздела NFS-шару. Хочется, чтобы он мог независимо от сервера принимать решения о доступе к файлам на корневом разделе. Как я понимаю, для решения проблемы есть два пути:
1. mapping uid и gid
2. использование опции no_acl для соответствующей шары в /etc/exports на сервере

Первый путь я неосилил. Для NFS версий 2 и 3 были опции map_* и специальный демон ugidd, для NFS версии 4 есть демон idmapd. ugidd из современных дистрибутивов выпилен. idmapd отсутствует в старых системах. И я не смог заставить его работать: если я говорю ядру бездисковой системы

APPEND root=/dev/nfs rootfstype=nfs4 initrd=initrd.img nfsroot=x.x.x.x:/srv/diskless_root ip=dhcp rw vga=791

mount -t nfs4 ... 

Про второй путь man exports говорит, что опция no_acl работает только на специально пропатченных ядрах. Следов этого патча в интернетах почти нет. Просто добавить эту опцию в exports не помогает.

В общем выхода я пока не вижу, так что буду рад услышать советы.

P.S.
Возможно есть другая сетевая файловая система, распространенная примерно так-же как и NFS, которая лучше подходит для моей задачи?

P.P.S.
Основная проблема даже не в различии uid и gid на сторонах клиента и сервера, а в том, что содержимое /etc/group на клиенте теряет силу.

Привет, ЛОР!
Написал некую программу на C, в ней достаточно активно используются треды. Жизнь треда начинается через pthread_create и заканчивается через pthread_cancel. Через pthread_attr функции pthread_create сообщается тип треда (JOINABLE или DETACHED). Вся динамически выделенная память освобождается в функции, назначенной треду через pthread_cleanup_push/pop.
После прогона программы под Valgrind выяснилось следующее:
* Если тред создан как JOINABLE (в этом случае после cancel вызывается join), то остаются possibly lost куски памяти, по одному на каждый созданный тред.
* Если тред создан как DETACHED (в этом случае после create дополнительно вызывается detach) вся память освобождается корректно.

Если верить man-у, то и join и detach освобождают все ресурсы, выделенные при создании треда.

В интернетах эту тему обсуждали в 2006-8 годах, некоторые предлагали вызывать detach после join и наоборот, но это попахивает бредом. Единого мнения я не нашел. Некоторые, кстати, считают, что на подобные утечки можно просто забить - дескать, все так и должно работать. Так ли это?

P.S.
Все это безобразие происходит под Ubuntu 9.10 x86