1.4, Funt (?), 20:54, 09/08/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
что ж совсем неплохо ждем 4-ку, тогда win2k3-8 можно будет выкидывать
| |
|
2.5, metallic (ok), 20:57, 09/08/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
Не надо их никуда выкидывать, когда самба 4 выйдет - вин2к8 уже поддерживаться не будет производителем, т.е. сама выкенится
| |
|
1.6, Аноним (6), 21:41, 09/08/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> пока отсутствует поддержка ldap
это в смысле теперь контроллер домена NT4-style не сможет в LDAP пользователей хранить? или это о чем-то другом речь?
| |
|
2.10, ptr (??), 09:49, 10/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
Получается так :( По крайней мере сейчас соответствие между SID UnixID хранится непосредственно в записи пользователя. По крайней мере классы inetOrgPerson, posixAccount,
shadowAccount и sambaSamAccount привязаны к этой одной записи.
В таком раскладе, лично мне такая Samba абсолютно не интересна.
| |
|
1.8, Аноним (-), 02:16, 10/08/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Если вкратце: SMB2 до конца не допилили, idmap сломали. Не самый удачный релиз.
Надеюсь, дальше будет лучше.
| |
1.11, metallic (ok), 10:18, 10/08/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
А на практике этот самый SMB2 что даст? Это как-то на производительности скажется или что? Проще говоря зачем оно мне?
| |
|
2.12, ptr (??), 10:34, 10/08/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А на практике этот самый SMB2 что даст? Это как-то на производительности
> скажется или что? Проще говоря зачем оно мне?
На производительности скажется положительно. Особенно на высокоскоростных линках с большой задержкой. Так как SMB1 не позволял послать новую команду, пока не получен ответ на предыдущую, а SMB2 позволяет.
Так же существенно выростет скорость на высокоскоростных линках (гигабит и выше), за счет снятия ограничения на размер блока в 64К. Теперь допустимы блоки до 4 гигабайт. То есть, большие файлы копироваться будут заметно быстрее.
Ну для меня еще интересна поддержка symbolic links.
| |
|
3.13, metallic (ok), 10:36, 10/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Так же существенно выростет скорость на высокоскоростных линках (гигабит и выше), за
> счет снятия ограничения на размер блока в 64К. Теперь допустимы блоки
> до 4 гигабайт. То есть, большие файлы копироваться будут заметно быстрее.
Вот это интересно, у меня как раз гигабитная сетка и высокая нагрузка на самбу. Для увеличения размера блока надо самому указывать какой-то параметр в конфиге или оно по умолчанию включено?
| |
|
4.14, ptr (??), 10:55, 10/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> Так же существенно выростет скорость на высокоскоростных линках (гигабит и выше), за
>> счет снятия ограничения на размер блока в 64К. Теперь допустимы блоки
>> до 4 гигабайт. То есть, большие файлы копироваться будут заметно быстрее.
> Вот это интересно, у меня как раз гигабитная сетка и высокая нагрузка
> на самбу. Для увеличения размера блока надо самому указывать какой-то параметр
> в конфиге или оно по умолчанию включено?
По идее, клиент с сервером должны сами договариваться о размере блока, если raw read = yes в smb.conf. Точнее, если не стоит raw read = no, так как уже давно оно yes по-умолчанию. Естественно, XP и ниже больше чем на 64К не согласятся. Samba без поддержки SMB2 тоже. А вот есть ли еще какой-то параметр на это влияющий, я не в курсе.
| |
|
5.15, metallic (ok), 11:01, 10/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
> По идее, клиент с сервером должны сами договариваться о размере блока, если
> raw read = yes в smb.conf. Точнее, если не стоит raw
> read = no, так как уже давно оно yes по-умолчанию. Естественно,
> XP и ниже больше чем на 64К не согласятся. Samba без
> поддержки SMB2 тоже. А вот есть ли еще какой-то параметр на
> это влияющий, я не в курсе.
Понятно, т.е. при "встрече" клиента поддерживающего SMB2 (7, виста) и сервера (samba >3.6), они сами "договорятся" об увеличении блока?
| |
|
6.16, ptr (??), 11:44, 10/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Понятно, т.е. при "встрече" клиента поддерживающего SMB2 (7, виста) и сервера (samba
> >3.6), они сами "договорятся" об увеличении блока?
Договорится 2008 сервер с вистой или семеркой. А договорится ли Samba 3.6 вместо 2008-го я не проверял и утверждать не берусь, пока сам не проверю.
| |
|
7.17, metallic (ok), 11:45, 10/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
А как это проверить можно? Как узнать по какому протоколу обмен идет в данный момент? Снифером заголовки глядеть?
| |
|
8.18, ptr (??), 11:54, 10/08/2011 [^] [^^] [^^^] [ответить] | +/– | ![](/avatar/bba7e1ce723b4b85f8ce40e964ee953f.jpg) А на фига Я проверять буду просто сравнивая скорость копирования больших файлов... текст свёрнут, показать | |
|
|
|
|
|
|
|
1.19, Аноним (19), 16:57, 10/08/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
In SMB 2.1 this maximum data unit was increased from 64 kilobytes (KB) to 1 megabyte (MB)
В версии блок увеличен с 64кб до 1 мегабайта, а не 1 гигабайта.
Сама 3.6.0 поддерживает SMB 2.0, которая не поддерживает блок 1мб, а всего лишь 64кб.
| |
|
2.20, ptr (??), 10:12, 11/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
По-моему, мы говорим о разных вещах. На 10 гигабитных сетях и более скоростных MTU можно использовать не 1500, и даже не 9000, а вплоть до мегабайта. И действительно, поддержка MTU более 64К появилась только в SMB 2.1. Если кто пользуется 10 гигабиткой пусть порадуется.
А вот размер блока, пересылаемого на один запрос клиента раньше был лимитирован 2-х байтным полем длины - 64К. В SMB2 это поле увеличено до 4-х байт. Никаких ограничений на размер запрашиваемого блока в спецификации нет.
| |
|
1.22, Денис (??), 10:19, 12/08/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А прозрачного монтирования еще не запилили ? чтобы обходиться без smbnet + fuse
Вот чтобы тот же самый функционал что и в smbnet тока чтобы в ядре был.
| |
|
2.23, Andrey Mitrofanov (?), 11:30, 12/08/2011 [^] [^^] [^^^] [ответить]
| +/– |
cifs модуль ядра [linux] не является частью пакета samba.
Насколько я ничего в этом не понимаю, кто его пилит вообще непонятно, но внимания ему уделяется немного. Новых разработок и фич не видно вовсе. Возможно, я что-то пропустил.
| |
|
|