Verifique se o sistema de arquivos aparece na saída de grep -w sync /proc/mounts . Spoiler: a resposta é não. Montar um sistema de arquivos com sincronização imediata é extremamente lento. (Também causa muitas gravações pequenas, o que reduziria a vida útil dos dispositivos flash.)
Alguns aplicativos descarregam os dados no disco chamando fdatasync . Infelizmente, as APIs do Unix não são bem projetadas quando se trata de resiliência¹. Do ponto de vista do aplicativo, algumas alterações precisam ser resilientes, porque o aplicativo transmitiu dados para uma máquina remota, indicando que a alteração foi salva. Nesse caso, fdatasync é a interface correta. Mas muitos aplicativos precisam de algo diferente: a garantia de que, se fizerem a alteração 1 seguida da alteração 2 e o sistema travar no meio do caminho, depois da reinicialização não haverá alteração 2 sem a alteração 1. (Exemplo: alterar 1 = gravar uma nova versão de um arquivo, altere 2 = excluindo a versão antiga.) Sistemas de arquivos reordenam as gravações do sistema de arquivos para desempenho; normalmente isso é invisível para os aplicativos, já que é apenas sobre o que acontece entre o cache / buffer do sistema de arquivos e o disco, não sobre qualquer coisa que seja visível para os aplicativos. Mas, em caso de falha do sistema, o conteúdo do disco reflete a ordem das gravações reais do disco. Não há API para dizer “essa alteração deve ocorrer antes dessa alteração”, portanto, os aplicativos usam fdatasync como reversão de um homem pobre (execute a alteração 1, chame fdatasync para garantir que ela tenha sido propagada para o disco e execute a alteração 2 ). Isso pode ter um impacto negativo no desempenho, especialmente em mídias com gravações lentas, como flash.
Se um aplicativo for excessivamente lento em seu sistema devido ao uso excessivo de fdatasync ou seu primo fsync , você poderá usar eatmydata para anular as chamadas fsync / fdatasync . Mas cuidado, se o seu sistema falhar no meio, você pode ficar com dados inconsistentes.
Não tenho certeza se minha resposta é relevante para recuperar ou alterar as configurações de um complemento do Firefox. Essa operação pode ser leitura do disco. Especialmente recordar - seu trabalho é ler um monte de dados!
Além disso, mesmo que as alterações não sejam sincronizadas no disco imediatamente, você pode esperar que alguns dos dados sejam gravados. Se os dados não forem gravados no disco, eles deverão permanecer na memória e, enquanto isso, a memória não poderá ser usada para outras coisas mais úteis. Além disso, seria um desperdício não manter o disco ocupado: se houver dados a serem gravados, o kernel começará a escrevê-lo, enquanto o aplicativo continua a executar e produzir mais dados.
¹ A resiliência, no contexto do design do sistema de arquivos, é a questão de se uma mudança no sistema de arquivos será preservada se o sistema falhar.