Заботится ли планировщик ядра Linux о количестве сокетов/ядер/потоков?
Изchown(2)
Only a privileged process (Linux: one with the CAP_CHOWN capability) may change the owner of a file. The owner of a file may change the group of the file to any group of which that owner is a member
Если userне является частью группы ftpgroup, то userне может измениться на группу файла или каталога на ftpgroup. Чтобы решить эту проблему, вы можете добавить userв группу ftpgroup, запустив
usermod -a -G ftpgroup user
на сервере как root.
В качестве альтернативы, если ожидается, что /var/ftp/user@domain.com/files/rsync_backup/будет содержать только файлы, принадлежащие группе ftpgroup, вы можете изменить владельца /var/ftp/user@domain.com/files/rsync_backup/на ftpgroupи установить бит setgidв каталоге
chown :ftpgroup /var/ftp/user@domain.com/files/rsync_backup/
chmod g+s /var/ftp/user@domain.com/files/rsync_backup/
Бит setgidв каталоге заставляет все вновь созданные файлы в этом каталоге иметь групповое владение каталогом и аналогично с каталогами, но также устанавливает для них бит setgid. Если в /var/ftp/user@domain.com/files/rsync_backup/есть какие-либо существующие файлы и каталоги, вам придется вручную изменить владельца и установить биты setgidв каталогах.
Нет, Linux не заботится о сокетах. Ознакомьтесь с документацией Kernel.org по топологии ЦП . Этот соответствующий отрывок должен пролить свет на ситуацию.
The kernel does not care about the concept of physical sockets because a socket has no relevance to software. It's an electromechanical component. In the past a socket always contained a single package (see below), but with the advent of Multi Chip Modules (MCM) a socket can hold more than one package.
По умолчанию Openstack делает количество сокетов равным количеству виртуальных ЦП. Из OpenStack Wiki этот отрывок (акцент мой):
Each virtualization driver in OpenStack has its own approach to defining the CPU topology seen by guest virtual machines. The libvirt driver will expose all vCPUs as individual sockets, with 1 core and no hyper-threads.
UNIX operating systems will happily use any CPU topology that is exposed to them within a upper bound on the total number of logical CPUs. That said there can be performance implications from choosing different topologies. For example, 2 hyper-threads are usually not equivalent in performance to 2 cores or sockets, and as such operating system schedulers have special logic to deal with task placement. So if a host has a CPU with 2 cores with 2 threads, and two tasks to run, it will try to place them on different cores, rather than in different threads within a core. It follows that if a guest is shown 4 sockets, the operating system will not be making optimal scheduler placement decisions to avoid competing for constrained thread resources.
Таким образом, у нас есть противоречивая информация из документации ядра Linux и документации Openstack. В документации по ядру Linux говорится, что сокеты — это бессмысленный термин в общей схеме вещей теперь, когда у нас есть многочиповые -модули. Однако похоже, что Openstack указывает, что планировщик UNIX предпочтет «физические ядра» «логическим ядрам» для задач и столкнется с ограничениями, рассматривая каждое ядро как отдельный сокет. Однако это не учитывает масштабируемость Openstack или виртуальных машин. Если Openstack работает на кластере серверов, имеет ли смысл ограничивать число ядер одним сокетом?
Так важно ли для вас , чтобы ваша виртуальная топология вашей виртуальной машины совпадала с вашей физической топологией? Будет ли ваша физическая топология когда-либо представлять собой «облако» или иным образом в виде кластера из множества серверов?