1. 20 2月, 2013 2 次提交
  2. 07 2月, 2013 1 次提交
  3. 20 1月, 2013 5 次提交
  4. 15 1月, 2013 4 次提交
  5. 18 12月, 2012 2 次提交
    • L
      Btrfs: fix a bug of per-file nocow · 213490b3
      Liu Bo 提交于
      Users report a bug, the reproducer is:
      $ mkfs.btrfs /dev/loop0
      $ mount /dev/loop0 /mnt/btrfs/
      $ mkdir /mnt/btrfs/dir
      $ chattr +C /mnt/btrfs/dir/
      $ dd if=/dev/zero of=/mnt/btrfs/dir/foo bs=4K count=10;
      $ lsattr /mnt/btrfs/dir/foo
      ---------------C- /mnt/btrfs/dir/foo
      $ filefrag /mnt/btrfs/dir/foo
      /mnt/btrfs/dir/foo: 1 extent found    ---> an extent
      $ dd if=/dev/zero of=/mnt/btrfs/dir/foo bs=4K count=1 seek=5 conv=notrunc,nocreat; sync
      $ filefrag /mnt/btrfs/dir/foo
      /mnt/btrfs/dir/foo: 3 extents found   ---> with nocow, btrfs breaks the extent into three parts
      
      The new created file should not only inherit the NODATACOW flag, but also
      honor NODATASUM flag, because we must do COW on a file extent with checksum.
      Signed-off-by: NLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      213490b3
    • C
      Btrfs: fix hash overflow handling · 9c52057c
      Chris Mason 提交于
      The handling for directory crc hash overflows was fairly obscure,
      split_leaf returns EOVERFLOW when we try to extend the item and that is
      supposed to bubble up to userland.  For a while it did so, but along the
      way we added better handling of errors and forced the FS readonly if we
      hit IO errors during the directory insertion.
      
      Along the way, we started testing only for EEXIST and the EOVERFLOW case
      was dropped.  The end result is that we may force the FS readonly if we
      catch a directory hash bucket overflow.
      
      This fixes a few problem spots.  First I add tests for EOVERFLOW in the
      places where we can safely just return the error up the chain.
      
      btrfs_rename is harder though, because it tries to insert the new
      directory item only after it has already unlinked anything the rename
      was going to overwrite.  Rather than adding very complex logic, I added
      a helper to test for the hash overflow case early while it is still safe
      to bail out.
      
      Snapshot and subvolume creation had a similar problem, so they are using
      the new helper now too.
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      Reported-by: NPascal Junod <pascal@junod.info>
      9c52057c
  6. 17 12月, 2012 8 次提交
  7. 13 12月, 2012 5 次提交
  8. 26 10月, 2012 2 次提交
  9. 12 10月, 2012 2 次提交
  10. 09 10月, 2012 2 次提交
    • S
      Btrfs: make filesystem read-only when submitting barrier fails · 5af3e8cc
      Stefan Behrens 提交于
      So far the return code of barrier_all_devices() is ignored, which
      means that errors are ignored. The result can be a corrupt
      filesystem which is not consistent.
      This commit adds code to evaluate the return code of
      barrier_all_devices(). The normal btrfs_error() mechanism is used to
      switch the filesystem into read-only mode when errors are detected.
      
      In order to decide whether barrier_all_devices() should return
      error or success, the number of disks that are allowed to fail the
      barrier submission is calculated. This calculation accounts for the
      worst RAID level of metadata, system and data. If single, dup or
      RAID0 is in use, a single disk error is already considered to be
      fatal. Otherwise a single disk error is tolerated.
      
      The calculation of the number of disks that are tolerated to fail
      the barrier operation is performed when the filesystem gets mounted,
      when a balance operation is started and finished, and when devices
      are added or removed.
      Signed-off-by: NStefan Behrens <sbehrens@giantdisaster.de>
      5af3e8cc
    • L
      Btrfs: fix off-by-one in file clone · aa42ffd9
      Liu Bo 提交于
      Btrfs uses inclusive range end for lock_extent(), unlock_extent() and
      related functions, so we made off-by-one errors in file clone.
      
      This fixes it and also fixes some style problems.
      Signed-off-by: NLiu Bo <bo.li.liu@oracle.com>
      aa42ffd9
  11. 04 10月, 2012 1 次提交
    • D
      btrfs: allow setting NOCOW for a zero sized file via ioctl · 7e97b8da
      David Sterba 提交于
      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: NDavid Sterba <dsterba@suse.cz>
      7e97b8da
  12. 02 10月, 2012 6 次提交