1. 01 9月, 2013 1 次提交
    • J
      Btrfs: check our parent dir when doing a compare send · ebdad913
      Josef Bacik 提交于
      When doing a send with a parent subvol we will check to see if the file we are
      acting on is being overwritten and move it if we think it may be needed further
      down the line during the send.  We check this by checking its directory and
      making sure it existed in the parent and making sure the file existed in the
      parent.  The problem with this check is that if we create a directory and a file
      in that directory, and then snapshot, and then remove and re-create that same
      directory and file with different inode numbers and then try to snapshot and
      send with the original parent we will try and save the original file inside of
      that directory.  This is a problem because during the receive we move the
      directory out of the way because it is a completely new inode, which makes us
      unable to find the old file inside of the directory when we try to move that out
      of the way for the overwrite.  We fix this by checking the parent directory of
      the inode we think we are overwriting.  If the parent directory generation in
      the send root != the parent directory generation in the parent root then we know
      it is a completely new directory and we need not bother with moving the file out
      of the way because it would have been completely destroyed.  This fixes bz
      60673.  Thanks,
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      Signed-off-by: NChris Mason <chris.mason@fusionio.com>
      ebdad913
  2. 14 6月, 2013 4 次提交
  3. 07 5月, 2013 4 次提交
    • E
      btrfs: make static code static & remove dead code · 48a3b636
      Eric Sandeen 提交于
      Big patch, but all it does is add statics to functions which
      are in fact static, then remove the associated dead-code fallout.
      
      removed functions:
      
      btrfs_iref_to_path()
      __btrfs_lookup_delayed_deletion_item()
      __btrfs_search_delayed_insertion_item()
      __btrfs_search_delayed_deletion_item()
      find_eb_for_page()
      btrfs_find_block_group()
      range_straddles_pages()
      extent_range_uptodate()
      btrfs_file_extent_length()
      btrfs_scrub_cancel_devid()
      btrfs_start_transaction_lflush()
      
      btrfs_print_tree() is left because it is used for debugging.
      btrfs_start_transaction_lflush() and btrfs_reada_detach() are
      left for symmetry.
      
      ulist.c functions are left, another patch will take care of those.
      Signed-off-by: NEric Sandeen <sandeen@redhat.com>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      48a3b636
    • T
      Btrfs: fix error handling in btrfs_ioctl_send() · ecc7ada7
      Tsutomu Itoh 提交于
      fget() returns NULL if error. So, we should check NULL or not.
      Signed-off-by: NTsutomu Itoh <t-itoh@jp.fujitsu.com>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      ecc7ada7
    • T
      Btrfs: remove unused variable in __process_changed_new_xattr() · ba1eeaac
      Tsutomu Itoh 提交于
      Variable 'p' is not used any more. So, remove it.
      Signed-off-by: NTsutomu Itoh <t-itoh@jp.fujitsu.com>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      ba1eeaac
    • S
      Btrfs: allow omitting stream header and end-cmd for btrfs send · c2c71324
      Stefan Behrens 提交于
      Two new flags are added to allow omitting the stream header and the
      end command for btrfs send streams. This is used in cases where you
      send multiple snapshots back-to-back in one stream.
      
      This used to be encoded like this (with 2 snapshots in this example):
      <stream header> + <sequence of commands> + <end cmd> +
      <stream header> + <sequence of commands> + <end cmd> + EOF
      
      The new format (if the two new flags are used) is this one:
      <stream header> + <sequence of commands> +
                        <sequence of commands> + <end cmd>
      
      Note that the currently existing receivers treat <end cmd> only as
      an indication that a new <stream header> is following. This means,
      you can just skip the sequence <end cmd> <stream header> without
      loosing compatibility. As long as an EOF is following, the currently
      existing receivers handle the new format (if the two new flags are
      used) exactly as the old one.
      
      So what is the benefit of this change? The goal is to be able to use
      a single stream (one TCP connection) to multiplex a request/response
      handshake plus Btrfs send streams, all in the same stream. In this
      case you cannot evaluate an EOF condition as an end of the Btrfs send
      stream. You need something else, and the <end cmd> is just perfect
      for this purpose.
      
      The summary is:
      The format change is driven by the need to send several Btrfs send
      streams over a single TCP connections, with the ability for a repeated
      request/response handshake in the middle. And this format change does
      not break any existing tool, it is completely compatible.
      
      You could compare the old behaviour of the Btrfs send stream to the
      one of ftp where you need a seperate request/response channel and
      newly opened data transfer channels for each file, while the new
      behaviour is more like http using a single stream for everything.
      Signed-off-by: NStefan Behrens <sbehrens@giantdisaster.de>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      c2c71324
  4. 28 3月, 2013 1 次提交
  5. 23 2月, 2013 1 次提交
  6. 21 2月, 2013 2 次提交
  7. 15 1月, 2013 1 次提交
  8. 17 12月, 2012 1 次提交
  9. 26 10月, 2012 3 次提交
  10. 04 10月, 2012 1 次提交
  11. 02 10月, 2012 21 次提交