Вы сузили свое горлышко бутылки к сети уже?
Вы не упоминаете, какая дисковая система находится в этом сервере. Но GigE должен дать Вам о 100MB/s +/-10 МБ. Существуют другие включенные факторы, но этот - большой. Таким образом, если Ваша дисковая подсистема просто 2 диска RAID1 (зеркало) затем дисковая подсистема не будет способной насыщать ссылку GigE во-первых.
В то время как setgid файл/двоичный файл не мог бы быть очевидно полезным, я определенно нахожу, что setgid укусил очень полезный примененный на каталоги. Принятие Вас является частями различных рабочих групп, которые у каждого есть их собственный Unix (разрешение) группы. Конечно, Вы затем хотели бы поместить setgid, обдумал папки проекта, удостоверившись, что правильное владение группы применяется при создании новых файлов и таким образом разрешения коллег в том групповом доступе проекта к тем файлам?
Основное использование должно сохранить владельца группы дерева файлов:
[lockie@bubbles tmp]$ mkdir dir1 && touch dir1/file && mkdir dir1/dir
[lockie@bubbles tmp]$ mkdir dir2 && chgrp staff dir2 && chmod 2755 dir2 && touch dir2/file && mkdir dir2/dir
[lockie@bubbles tmp]$ ls -al dir1
total 32
drwxrwxr-x 3 lockie lockie 4096 Dec 13 19:32 .
drwxrwxrwt 125 root root 20480 Dec 13 19:32 ..
drwxrwxr-x 2 lockie lockie 4096 Dec 13 19:32 dir
-rw-rw-r-- 1 lockie lockie 0 Dec 13 19:32 file
[lockie@bubbles tmp]$ ls -al dir2
total 32
drwxr-sr-x 3 lockie staff 4096 Dec 13 19:32 .
drwxrwxrwt 125 root root 20480 Dec 13 19:32 ..
drwxrwsr-x 2 lockie staff 4096 Dec 13 19:32 dir < note new dir is g+s, owned by "staff" group, so the setgid behaviour acts recursively
-rw-rw-r-- 1 lockie staff 0 Dec 13 19:32 file < note new file is owned by "staff" group
[lockie@bubbles tmp]$
Это имеет тенденцию быть полезным в средах, где различные пользователи будут создавать/редактировать файлы/директоров в соответствии с каталогом: Когда все файлы/директора совместно используют ту же группу, все пользователи могут редактировать/изменять файлы/директоров (разрешение полномочий): Это избегает ситуаций такой, поскольку "xyz владеет abc файла, таким образом, я не могу отредактировать ее".
Альтернатива использованию setgid таким образом является grpid файловой системой, монтируют опцию.
От человека смонтируйтесь:
grpid или bsdgroups / nogrpid или sysvgroups
Эти опции определяют, какой идентификатор группы недавно созданный файл получает. Когда grpid установлен, он берет идентификатор группы каталога, в котором он создается; иначе (значение по умолчанию) это берет fsgid текущего процесса, если каталог не имеет setgid набор битов, в этом случае это берет ценуроз из родительского каталога и также получает setgid набор битов, если это - сам каталог.
При включении файлы/директора, созданные на grpid, смонтировали, что файловая система также наследовала группу родительского каталога:
[lockie@bubbles ~]$ mount | grep /home
/dev/mapper/VolGroup00-home on /home type ext3 (rw,grpid)
[lockie@bubbles ~]$ mkdir dir3 && touch dir3/file && mkdir dir3/dir
[lockie@bubbles ~]$ ls -al dir3
total 12
drwxrwxr-x 3 lockie users 4096 Dec 13 19:37 .
drwxrwxr-x 12 lockie users 4096 Dec 13 19:37 ..
drwxrwxr-x 2 lockie users 4096 Dec 13 19:37 dir < inherited "users" group from parent dir
-rw-rw-r-- 1 lockie users 0 Dec 13 19:37 file < inherited "users" group from parent dir
[lockie@bubbles ~]$
Я нашел, что использование grpid опция соответственно уменьшает шанс для человеческой ошибки (так как файловая система делает работу, независимо от полномочий dir).