Rich's questions

Temos sistemas com discos mecânicos giratórios e armazenamento NVME. Queremos reduzir a sobrecarga da CPU para E/S eliminando qualquer agendador de E/S. Queremos especificar isso na linha de comando de inicialização do Linux; ou seja, em GRUB_CMDLINE_LINUX, no arquivo /etc/default/grub.

• Para discos mecânicos, podemos anexar elevator=noopà linha de comando. Isso corresponde ao noopvalor em/sys/block/sda/queue/scheduler
• Para armazenamento NVME, usamos noneem /sys/block/nvme0n1/queue/scheduler; que presumivelmente (não foi possível confirmar) pode ser especificado no momento da inicialização anexando elevator=none.

Isso se torna uma questão de duas partes:

1. O elevator=nonevalor correto a ser usado para armazenamento NVME está em GRUB_CMDLINE_LINUX?
2. Ambos os valores podem ser especificados em GRUB_CMDLINE_LINUX?

Se o segundo estiver correto, suponho que elevator=noopserá definido corretamente para os discos giratórios, mas o controlador NVME o ignorará normalmente; then elevator=noneserá definido corretamente para discos NVME, mas o controlador de disco giratório ignorará isso .

Se eu criar um arquivo como um usuário sem privilégios e alterar o modo de permissão para 400, ele será visto por esse usuário como somente leitura, corretamente:

$ touch somefile
$ chmod 400 somefile
$ [ -w somefile ] && echo rw || echo ro
ro

Tudo está bem.

Mas então o root aparece:

# [ -w somefile ] && echo rw || echo ro
rw

Que diabos? Claro, o root pode gravar em arquivos somente leitura, mas não deve tornar isso um hábito: as melhores práticas tenderiam a ditar que eu deveria ser capaz de testar o bit de permissão de gravação e, se não for, então foi definido assim por uma razão.

Acho que quero entender por que isso está acontecendo e como posso obter um código de retorno falso ao testar um arquivo que não possui o bit de gravação definido?