Skip to content
Snippets Groups Projects
Select Git revision
  • 571640cad3fda6475da45d91cf86076f1f86bd9b
  • vme-testing default
  • ci-test
  • master
  • remoteproc
  • am625-sk-ov5640
  • pcal6534-upstreaming
  • lps22df-upstreaming
  • msc-upstreaming
  • imx8mp
  • iio/noa1305
  • vme-next
  • vme-next-4.14-rc4
  • v4.14-rc4
  • v4.14-rc3
  • v4.14-rc2
  • v4.14-rc1
  • v4.13
  • vme-next-4.13-rc7
  • v4.13-rc7
  • v4.13-rc6
  • v4.13-rc5
  • v4.13-rc4
  • v4.13-rc3
  • v4.13-rc2
  • v4.13-rc1
  • v4.12
  • v4.12-rc7
  • v4.12-rc6
  • v4.12-rc5
  • v4.12-rc4
  • v4.12-rc3
32 results

ext4

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Eric Sandeen authored and Theodore Ts'o committed
    I can't think of any valid reason for ext4 to not use barriers when
    they are available;  I believe this is necessary for filesystem
    integrity in the face of a volatile write cache on storage.
    
    An administrator who trusts that the cache is sufficiently battery-
    backed (and power supplies are sufficiently redundant, etc...)
    can always turn it back off again.
    
    SuSE has carried such a patch for ext3 for quite some time now.
    
    Also document the mount option while we're at it.
    
    Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
    Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
    Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
    571640ca
    History
    Name Last commit Last update
    ..