1. 24 Oct, 2012 1 commit
  2. 23 Oct, 2012 2 commits
  3. 09 Oct, 2012 33 commits
  4. 04 Oct, 2012 4 commits
    • David Sterba's avatar
      btrfs: allow setting NOCOW for a zero sized file via ioctl · 7e97b8da
      David Sterba authored
      Hi,
      
      the patch si simple, but it has user visible impact and I'm not quite sure how
      to resolve it.
      
      In short, $subj says it, chattr -C supports it and we want to use it.
      
      The conditions that acutally allow to change the NOCOW flag are clear. What if
      I try to set the flag on a file that is not empty? Options:
      
      1) whole ioctl will fail, EINVAL
      2.1) ioctl will succeed, the NOCOW flag will be silently removed, but the file
           will stay COW-ed and checksummed
      2.2) ioctl will succeed, flag will not be removed and a syslog message will
           warn that the COW flag has not been changed
      2.2.1) dtto, no syslog message
      
      Man page of chattr states that
      
       "If it is set on a file which already has data blocks, it is undefined when
       the blocks assigned to the file will be fully stable."
      
      Yes, it's undefined and with current implementation it'll never happen. So from
      this end, the user cannot expect anything. I'm trying to find a reasonable
      behaviour, so that a command like 'chattr -R -aijS +C' to tweak a broad set of
      flags in a deep directory does not fail unnecessarily and does not pollute the
      log.
      
      My personal preference is 2.2.1, but my dev's oppinion is skewed, not counting
      the fact that I know the code and otherwise would look there before consulting
      the documentation.
      
      The patch implements 2.2.1.
      
      david
      
      -------------8<-------------------
      From: David Sterba <dsterba@suse.cz>
      
      It's safe to turn off checksums for a zero sized file.
      
      http://thread.gmane.org/gmane.comp.file-systems.btrfs/18030
      
      "We cannot switch on NODATASUM for a file that already has extents that
      are checksummed. The invariant here is that either all the extents or
      none are checksummed.
      
      Theoretically it's possible to add/remove all checksums from a given
      file, but it's a potentially longtime operation, the file has to be in
      some intermediate state where the checksums partially exist but have to
      be ignored (for the csum->nocsum) until the file is fully converted,
      this brings more special cases to extent handling, it has to survive
      power failure and remain consistent, and probably needs to be restarted
      after next mount."
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.cz>
      7e97b8da
    • Josef Bacik's avatar
      Btrfs: fix punch hole when no extent exists · c3308f84
      Josef Bacik authored
      I saw the warning in btrfs_drop_extent_cache where our end is less than our
      start while running xfstests 68 in a loop.  This is because we
      unconditionally do drop_end = min(end, extent_end) in
      __btrfs_drop_extents(), even though we may not have found an extent in the
      range we were looking to drop.  So keep track of wether or not we found
      something, and if we didn't just use our end.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      c3308f84
    • Josef Bacik's avatar
      Btrfs: don't do anything in our ->freeze_fs and ->unfreeze_fs · 926ced12
      Josef Bacik authored
      We do not need to do anything special to freeze or unfreeze, it's all taken
      care of by the generic work, and what we currently have is wrong anyway
      since we shouldn't be returnning to userspace with mutexes held anyway.
      Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      926ced12
    • Josef Bacik's avatar
      Btrfs: remove unused write cache pages hook · 892951a9
      Josef Bacik authored
      The btree inode has it's own write cache pages so we can remove this write
      cache pages hook as it's not used.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      892951a9