O que faz o omnislash ser diferente dos outros kernels, o que ele tem de interessante??
Devido ao grande número de perguntas desse tipo, vou postar algumas coisas que essa série tem que poucos kernels possuem e o que eles fazem realmente.
Aos poucos irei atualizando esse post.
Ext 3 barrier por padrão
Para dar mais segurança ao ext3 coloquei esse patch, isso ajuda reduzindo problemas de corrupção de dados ou até do sistema de arquivos durante um crash, que podem acontecer devido a uma falha de fornecimento de energia ou até um kernel panic na hora de escrever um simples dado.
Esse patch dá mais poder ao ext3 melhorando a sua segurança e confiabilidade ao sistema.
Veja esse trecho (em inglês):
http://en.wikipedia.org/wiki/Ext3
Ext3 does not do checksumming when writing to the journal. If barrier=1 is not enabled as a mount option (in /etc/fstab), and if the hardware is doing out-of-order write caching, one runs the risk of severe filesystem corruption during a crash.[13][14] (This option is not enabled by default on almost all popular Linux distributions, and thus most distributions are at risk.)
Consider the following scenario: If hard disk writes are done out-of-order (due to modern hard disks caching writes in order to amortize write speeds), it is likely that one will write a commit block of a transaction before the other relevant blocks are written. If a power failure or kernel panic should occur before the other blocks get written, the system will have to be rebooted. Upon reboot, the file system will replay the log as normal, and replay the “winners” (transactions with a commit block, including the invalid transaction above which happened to be tagged with a valid commit block). The unfinished disk write above will thus proceed, but using corrupt journal data. The file system will thus mistakenly overwrite normal data with corrupt data while replaying the journal. If checksums had been used (if the blocks of the “fake winner” transaction were tagged with mutual checksum), the file system could have known better and not replayed the corrupt data onto the disk.
A sua distribuição linux usa isso???
É simples use o comando abaixo e veja os resultados:
cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
/dev/disk/by-uuid/8d4928f0-5d48-4451-a9eb-73caecf20fd0 / ext3 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
/dev/disk/by-uuid/8d4928f0-5d48-4451-a9eb-73caecf20fd0 /dev/.static/dev ext3 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
tmpfs /var/run tmpfs rw,nosuid,nodev,noexec 0 0
tmpfs /var/lock tmpfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime 0 0
tmpfs /var/run tmpfs rw,nosuid,nodev,noexec 0 0
tmpfs /var/lock tmpfs rw,nosuid,nodev,noexec 0 0
/dev/sde5 /home ext3 rw,relatime,barrier=1,data=ordered 0 0
/dev/sde1 /media/sda1 fuseblk rw,nosuid,nodev,noatime,relatime,user_id=0,group_id=0,default_permissions,allow_other 0 0
Con Kolivas patchs
Um grande desenvolvedor que fez e inspirou diversas modificações no kernel, o CFS feito pelo Ingo Molnar foi feito inspirado no código fonte do Staircase Deadline do Con.
Os patches feitos pelo Con Kolivas (ck) vão otimizando desde o uso da memória, swap, cfq, etc e aumentam a performance e a resposta do sistema e ajudam também reduzindo o impacto do sistema de entrada e saída
Após algumas desavenças ele não continua mais fazendo esses patches mas a comunidade ainda continua mantendo os mesmos pois são muito bons.
Dessa vez peguei os patches do kernel “dark” do fórum gentoo por isso deixo o meu agradecimento a esse excelente patchset.
http://en.wikipedia.org/wiki/Con_Kolivas
Relatime
Esse patch ajuda bastante na performance do hd veja o que o Mandriva 2008 diz sobre o relatime:
Mandriva 2008 Wiki
Operações mais rápidas nas partições
Por padrão, o instalador configura sistema de arquivos para usar a opção relatime. Essa opção reduz drasticamente a quantidade de I/O utilizada pelo sistema na data de acesso de atualização quando um arquivo é lido ou quando um diretório é navegado. Assim o carregamento de máquinas desktop e servidor é drasticamente reduzido e muitas tarefas de I/O são concluídas mais rapidamente.
Para verificar se vc está usando o relatime faça o seguinte:
É simples use o comando abaixo e veja os resultados:
cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
/dev/disk/by-uuid/8d4928f0-5d48-4451-a9eb-73caecf20fd0 / ext3 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
/dev/disk/by-uuid/8d4928f0-5d48-4451-a9eb-73caecf20fd0 /dev/.static/dev ext3 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
tmpfs /var/run tmpfs rw,nosuid,nodev,noexec 0 0
tmpfs /var/lock tmpfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,relatime 0 0
devpts /dev/pts devpts rw,relatime 0 0
tmpfs /var/run tmpfs rw,nosuid,nodev,noexec 0 0
tmpfs /var/lock tmpfs rw,nosuid,nodev,noexec 0 0
/dev/sde5 /home ext3 rw,relatime,barrier=1,data=ordered 0 0
/dev/sde1 /media/sda1 fuseblk rw,nosuid,nodev,noatime,relatime,user_id=0,group_id=0,default_permissions,allow_other 0 0
Até eu concluir esse tópico vou demorar um tempinho então espere mais coisas
