Estou surpreso que a diferença seja ótima. Eu não sei a resposta e nunca comparei E / S em um sistema de inicialização dupla, mas tenho algumas idéias.
Eu não reconheço os erros que você recebeu do seu programa de benchmarking, mas eles não podem ser bons. Outro teste para você: há alguma anomalia em seus dados de automonitoramento de disco? (Por exemplo, execute gnome-disks e procure por dados SMART. Ele julga uma avaliação OK para todos os atributos?)
gnome-disks também podem executar testes isolados de leitura e gravação. Nunca executei um benchmark de gravação no meu SSD e nunca o farei, mas os benchmarks de leitura são sempre satisfatórios. Você está recebendo uma velocidade de E / S isolada anunciada? Também pode ser interessante separar velocidades de leitura e gravação separadas durante a sua cópia de arquivo, e comparar com aquelas velocidades isoladas do benchmark gnome-disk. iostat -m durante a cópia fornecerá esses números. (iostat está no pacote sysstat no Debian / Ubuntu.) Isso provavelmente não é um conselho muito prático, mas algo chocante poderia ser criado.
O seu sistema de arquivos Linux está em boa forma? fsck é o programa para descobrir, mas é difícil executar em um sistema de arquivos em funcionamento. É mais fácil eu pensar em sudo touch /forcefsck e reinicializar.
Diga, você não está usando o Ext3, está? Isto pode ser, se você atualizou para o Ubuntu 12.10 em uma distro antiga. O Ext3 não manipula arquivos do tamanho de gigabytes com a mesma eficiência que o Ext4. Talvez seja um fator. mount (apenas montar, sem parâmetros) identificará o sistema de arquivos em reprodução.
Você pode estar vendo um efeito dos programas que está usando para fazer a cópia do arquivo. O comando cp , por exemplo, não é muito rápido nem eficiente. (Eu entendo no entanto você está usando alguma GUI, não cp. Isso adiciona mais variáveis embora. Você nunca sabe o que um programa está realmente pensando por trás de sua GUI.)
Não consigo imaginar noatime teria qualquer efeito mensurável na velocidade de cópia de um único arquivo. (Mesmo assim, eu uso no meu SSD.) discard não ajuda, e pode atrasar a cópia. Descarte você sabe, incentiva o sistema de arquivos para cuidar da memória flash apagar apagar o mais cedo possível. Não estou certo de que isso funcione no Ubuntu 12.10 / kernel 3.5. De qualquer forma, para melhores resultados de benchmark, você é mais bem servido pelo TRIMMER um SSD antes do teste, e isso pode fazer uma grande diferença na velocidade de gravação. sudo fstrim /home por exemplo.
A web está cheia de conselhos para outros ajustes de desempenho. É um conselho comum da SSD ajustar o entusiasmo do agendador de E / S de disco e do sistema de arquivos. Aqui está um tópico exaltando as virtudes do registro de dados = registro de retorno de publicação . Na minha opinião, esse conselho é um pouco impreciso, mas pode fazer a diferença. Algumas configurações de diário seriam genuinamente mais lentas, mas você não usaria dados = diário por acidente.
O que estou dizendo de qualquer maneira? O desempenho do sistema pode ser o lar de mil variáveis. Na minha opinião sobre algumas escolhas populares, em relação à velocidade de copiar um arquivo: noatime , eu não vejo isso. data=writeback possivelmente. discard certamente não. fstrim , possivelmente. fsck talvez. Fora dos preocupantes erros de E / S de benchmark que você mencionou, eu diria que o Ext3 ou um disco não-RTIM pode ser responsável por alguma parte da discrepância que você está vendo.