полнофункциональный адаптер USB WLAN
Фактические пределы могут зависеть и от файловой системы, которую Вы используете, и ядро.
Для обнаружения пределов для конкретной точки монтирования можно использовать getconf (напр. для / на моей машине):
$ getconf PATH_MAX /
4096
$ getconf NAME_MAX /
255
PATH_MAX максимальная общая длина, NAME_MAX если для имени файла. Пределы ядра находятся в include/linux/limits.h в источнике ядра:
#define NAME_MAX 255 /* # chars in a file name */
#define PATH_MAX 4096 /* # chars in a path name including nul */
Для списка пределов файловой системы посмотрите Сравнение файловых систем.
Пределы файловой системы диктуют максимальный уровень вложенности (если таковые имеются) для каталогов и затем длины имен файлов и имен каталогов для той файловой системы. Пределы ядра диктуют, какой длины строки, которые относятся к путям, могут быть.
У Вас может на самом деле быть вложенная структура, которая превышает PATH_MAX предел. Но Вы не сможете обратиться к нему с полностью определенным путем от корня. Необходимо также ожидать странные программные ошибки при использовании таких глубинных структур так как много кода ожидает, что пути будут соответствовать в PATH_MAX буферы, и проверяющий на ENAMETOOLONG ошибки (и правильно восстановление от них) являются, вероятно, не одним из лучше всего протестированных путей выполнения кода там.
Что касается организации, просто используйте любые более естественные чувства. Сохраните иерархии разумными, избегайте странных символов (и пробел), если Вы хотите быть script-safe/friendly. Те пределы довольно щедры. Если Вы когда-нибудь добираетесь рядом PATH_MAX, пора, вероятно, реорганизовать вещи.
Если Вы действительно хотите проверить, как вещи ведут себя в очень длинных путях, вот быстрый способ генерировать огромные пути:
#! /usr/bin/perl
my $kd = "a" x 255;
for my $i (1..64) {
mkdir($kd); chdir($kd);
}
Если Вы хотите глубокую иерархию, попробуйте:
#! /usr/bin/perl
my $kd = "a";
for my $i (1..8192) {
mkdir($kd); chdir($kd);
}
И можно добраться:
$ pwd | wc -c
16394
Но ksh становится немного перепутанным:
$ cd ..
ksh: cd: ..: [File name too long]
bash действительно делает cd .., но подсказка испорчена, имя каталога не разрешено - так pwd | wc -c на самом деле 16397 после этого.
Тем временем я купил и протестировал некоторые устройства. Мой выбор был высоко вдохновлен списком, предложенным @Renat. Здесь, я компилирую свои результаты.
Неисправность AVM
Маленький вариант Палки Fritz Wlan AVM N поддерживает только 2,4 ГГц, в то время как большой имеет многополосную поддержку с 2,4 и 5 ГГц. Оба полагаются на carl9170 модуль драйвера. Используемый в качестве клиентов, они - оба катастрофа. Они регулярно отказывают. Ядро перезапускает их в меньше затем секунде, но повторно подключение является необходимым и трудоемким. Соединения в реальном времени невозможны, уже не говоря о вещах как SSH. Кроме того, проблема, кажется, накапливает. Чем дольше я использовал палки, тем более частый они действительно отказывали, приводя к палке который работавший несколько минут над максимумом. Настраивая параметры модуля, nohwcrypt и noht для сокращения нагрузки на оборудование устройства вызвал только временную поправку.
Тестируя многополосный в режиме точки доступа, однако, это работало безупречное. Потоковая передача видео и sftp передача файлов работали с полными 300 Мбит/с.
Ссылка TP
Со Ссылкой TP у меня снова был выбор между двухдиапазонным вариантом TL-WDN3200 и 2,4 ГГц только TL-WN821N. Первые потребности драйвер из дерева, который будет скомпилирован, таким образом, я сразу пропустил к модели единственной полосы. TL-WN821N использует ath9k_htc модуль, включенный в ядро Linux. даже имеет немного более высокую скорость передачи и качество соединения, чем модели Fritz, протестированные по двум этажам и некоторым стенам. Это также отказывает намного меньше, чем они, только несколько раз день. Но когда это делает, это компенсирует свою производительность путем замораживания значительных частей сетевой подсистемы. Каждый syscall, который пытается получить доступ к сетевому устройству (включая обратную петлю, на которую полагаются много Решений IPC) остановы и возврат привычки, пока устройство не отключается или модуль ядра, удален. Я пожертвовал его некоторому пользователю Windows, где это делает свою работу как клиент с тех пор.
Buffalo
Наконец, я испытал Buffalo WLI-UC-G300HP. Хотя это маркировано 300 Мбит/с также, это работает немного медленнее, чем вышеупомянутые. Качество соединения все еще хорошо всюду по некоторым стенам и этажам, особенно при использовании его небольшой корректируемой антенны, которой можно также махать далеко полностью, когда пространство является ограниченным. Я использую его в течение нескольких месяцев теперь и очень удовлетворен.
Его единственный дефект - то, что никакой драйвер автоматически не чувствует себя ответственным за это устройство. На самом деле это может использоваться с хорошо протестированным rt2800usb модулем. Существует две возможности преподавать это к ядру.
В Runtime
Проблема как корень
modprobe rt2800usb
echo 0411 01a8 > /sys/bus/usb/drivers/rt2800usb/new_id
Первая строка вставляет модуль. Второй говорит устройство и идентификатор продукта к драйверу. Эти числа могут быть найдены через lsusb, но должны быть те данные для WLI-UC-G300HP. Затем драйвер принимает управление модулем. Это могло быть сделано персистентным с правилом udev. Я, с моей стороны, выбираю другой метод
Компиляция ядра
При создании ядра сами так или иначе можно просто применить следующий патч.
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 098613e..2ded919 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -953,6 +953,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x0411, 0x016f) },
{ USB_DEVICE(0x0411, 0x01a2) },
{ USB_DEVICE(0x0411, 0x01ee) },
+ { USB_DEVICE(0x0411, 0x01a8) },
/* Corega */
{ USB_DEVICE(0x07aa, 0x002f) },
{ USB_DEVICE(0x07aa, 0x003c) },
Это добавляет идентификаторы к внутренней базе данных модуля так, чтобы это было внутренне мотивировано для управления устройством.
Большинство используемых мной высокоскоростной WLAN адаптеры USB основано на чипсетах Ralink. Я не уверен в, они поддерживают из поля в 3.7.1 ядрах, но некоторые специалисты по обслуживанию включает поддержку этого USB WLAN в их дистрибутивном по умолчанию. Также может быть эта ссылка быть интересным для Вас.