Skip to content

L
linux
Switch branch/tag
  1. 25 Apr, 2011 7 commits
    • Li Zefan's avatar
      Btrfs: Support reading/writing on disk free ino cache · 82d5902d
      Li Zefan authored 
      This is similar to block group caching.

We dedicate a special inode in fs tree to save free ino cache.

At the very first time we create/delete a file after mount, the free ino
cache will be loaded from disk into memory. When the fs tree is commited,
the cache will be written back to disk.

To keep compatibility, we check the root generation against the generation
of the special inode when loading the cache, so the loading will fail
if the btrfs filesystem was mounted in an older kernel before.
Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      82d5902d
    • Li Zefan's avatar
      Btrfs: Always use 64bit inode number · 33345d01
      Li Zefan authored 
      There's a potential problem in 32bit system when we exhaust 32bit inode
numbers and start to allocate big inode numbers, because btrfs uses
inode->i_ino in many places.

So here we always use BTRFS_I(inode)->location.objectid, which is an
u64 variable.

There are 2 exceptions that BTRFS_I(inode)->location.objectid !=
inode->i_ino: the btree inode (0 vs 1) and empty subvol dirs (256 vs 2),
and inode->i_ino will be used in those cases.

Another reason to make this change is I'm going to use a special inode
to save free ino cache, and the inode number must be > (u64)-256.
Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      33345d01
    • Li Zefan's avatar
      Btrfs: Make the code for reading/writing free space cache generic · 0414efae
      Li Zefan authored 
      Extract out block group specific code from lookup_free_space_inode(),
create_free_space_inode(), load_free_space_cache() and
btrfs_write_out_cache(), so the code can be used to read/write
free ino cache.
Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      0414efae
    • Li Zefan's avatar
      Btrfs: Cache free inode numbers in memory · 581bb050
      Li Zefan authored 
      Currently btrfs stores the highest objectid of the fs tree, and it always
returns (highest+1) inode number when we create a file, so inode numbers
won't be reclaimed when we delete files, so we'll run out of inode numbers
as we keep create/delete files in 32bits machines.

This fixes it, and it works similarly to how we cache free space in block
cgroups.

We start a kernel thread to read the file tree. By scanning inode items,
we know which chunks of inode numbers are free, and we cache them in
an rb-tree.

Because we are searching the commit root, we have to carefully handle the
cross-transaction case.

The rb-tree is a hybrid extent+bitmap tree, so if we have too many small
chunks of inode numbers, we'll use bitmaps. Initially we allow 16K ram
of extents, and a bitmap will be used if we exceed this threshold. The
extents threshold is adjusted in runtime.
Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      581bb050
    • Li Zefan's avatar
      Btrfs: Make free space cache code generic · 34d52cb6
      Li Zefan authored 
      So we can re-use the code to cache free inode numbers.

The change is quite straightforward. Two new structures are introduced.

- struct btrfs_free_space_ctl

  We move those variables that are used for caching free space from
  struct btrfs_block_group_cache to this new struct.

- struct btrfs_free_space_op

  We do block group specific work (e.g. calculation of extents threshold)
  through functions registered in this struct.

And then we can remove references to struct btrfs_block_group_cache.
Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      34d52cb6
    • Li Zefan's avatar
      Btrfs: Use bitmap_set/clear() · f38b6e75
      Li Zefan authored 
      No functional change.
Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      f38b6e75
    • Li Zefan's avatar
      Btrfs: Remove unused btrfs_block_group_free_space() · 92c42311
      Li Zefan authored 
      We've already recorded the value in block_group->frees_space.
Signed-off-by: default avatarLi Zefan <lizf@cn.fujitsu.com>
      92c42311
  3. 18 Apr, 2011 1 commit
    • Chris Mason's avatar
      Btrfs: fix free space cache leak · f65647c2
      Chris Mason authored 
      The free space caching code was recently reworked to
cache all the pages it needed instead of using find_get_page everywhere.

One loop was missed though, so it ended up leaking pages.  This fixes
it to use our page array instead of find_get_page.
Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      f65647c2
  5. 16 Apr, 2011 2 commits
  7. 15 Apr, 2011 1 commit
    • Chris Mason's avatar
      Btrfs: don't force chunk allocation in find_free_extent · 0e4f8f88
      Chris Mason authored 
      find_free_extent likes to allocate in contiguous clusters,
which makes writeback faster, especially on SSD storage.  As
the FS fragments, these clusters become harder to find and we have
to decide between allocating a new chunk to make more clusters
or giving up on the cluster to allocate from the free space
we have.

Right now it creates too many chunks, and you can end up with
a whole FS that is mostly empty metadata chunks.  This commit
changes the allocation code to be more strict and only
allocate new chunks when we've made good use of the chunks we
already have.
Signed-off-by: default avatarChris Mason <chris.mason@oracle.com>
      0e4f8f88
  9. 13 Apr, 2011 5 commits
  11. 12 Apr, 2011 8 commits
  13. 08 Apr, 2011 8 commits
    • Josef Bacik's avatar
      Btrfs: check for duplicate iov_base's when doing dio reads · 93a54bc4
      Josef Bacik authored 
      Apparently it is ok to submit a read to an IDE device with the same target page
for different offsets.  This is what Windows does under qemu.  The problem is
under DIO we expect them to be different buffers for checksumming reasons, and
so this sort of thing will result in checksum errors, when in reality the file
is fine.  So when reading, check to make sure that all iov bases are different,
and if they aren't fall back to buffered mode, since that will work out right.
Thanks,
Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      93a54bc4
    • Josef Bacik's avatar
      Btrfs: reuse the extent_map we found when calling btrfs_get_extent · 16d299ac
      Josef Bacik authored 
      In btrfs_get_block_direct we call btrfs_get_extent to lookup the extent for the
range that we are looking for.  If we don't find an extent, btrfs_get_extent
will insert a extent_map for that area and mark it as a hole.  So it does the
job of allocating a new extent map and inserting it into the io tree.  But if
we're creating a new extent we free it up and redo all of that work.  So instead
pass the em to btrfs_new_extent_direct(), and if it will work just allocate the
disk space and set it up properly and bypass the freeing/allocating of a new
extent map and the expensive operation of inserting the thing into the io_tree.
Thanks,
Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      16d299ac
    • Josef Bacik's avatar
      Btrfs: do not use async submit for small DIO io's · 1ae39938
      Josef Bacik authored 
      When looking at our DIO performance Chris said that for small IO's doing the
async submit stuff tends to be more overhead than it's worth.  With this on top
of my other fixes I get about a 17-20% speedup doing a sequential dd with 4k
IO's.  Basically if we don't have to split the bio for the map length it's small
enough to be directly submitted, otherwise go back to the async submit.  Thanks,
Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      1ae39938
    • Josef Bacik's avatar
      Btrfs: don't split dio bios if we don't have to · 02f57c7a
      Josef Bacik authored 
      We have been unconditionally allocating a new bio and re-adding all pages from
our original bio to the new bio.  This is needed if our original bio is larger
than our stripe size, but if it is smaller than the stripe size then there is no
need to do this.  So check the map length and if we are under that then go ahead
and submit the original bio.  Thanks,
Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      02f57c7a
    • Josef Bacik's avatar
      Btrfs: do not call btrfs_update_inode in endio if nothing changed · 1ef30be1
      Josef Bacik authored 
      In the DIO code we often don't update the i_disk_size because the i_size isn't
updated until after the DIO is completed, so basically we are allocating a path,
doing a search, and updating the inode item for no reason since nothing changed.
btrfs_ordered_update_i_size will return 1 if it didn't update i_disk_size, so
only run btrfs_update_inode if btrfs_ordered_update_i_size returns 0.  Thanks,
Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      1ef30be1
    • Josef Bacik's avatar
      Btrfs: map the inode item when doing fill_inode_item · 12ddb96c
      Josef Bacik authored 
      Instead of calling kmap_atomic for every thing we set in the inode item, map the
entire inode item at the start and unmap it at the end.  This makes a sequential
dd of 400mb O_DIRECT something like 1% faster.  Thanks,
Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      12ddb96c
    • Josef Bacik's avatar
      Btrfs: only retry transaction reservation once · 06d5a589
      Josef Bacik authored 
      I saw a lockup where we kept getting into this start transaction->commit
transaction loop because of enospce.  The fact is if we fail to make our
reservation, we've tried _everything_ several times, so we only need to try and
commit the transaction once, and if that doesn't work then we really are out of
space and need to just exit.  Thanks,
Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      06d5a589
    • Josef Bacik's avatar
      Btrfs: deal with the case that we run out of space in the cache · be1a12a0
      Josef Bacik authored 
      Currently we don't handle running out of space in the cache, so to fix this we
keep track of how far in the cache we are.  Then we only dirty the pages if we
successfully modify all of them, otherwise if we have an error or run out of
space we can just drop them and not worry about the vm writing them out.
Thanks,

Tested-by Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
Signed-off-by: default avatarJosef Bacik <josef@redhat.com>
      be1a12a0
  15. 05 Apr, 2011 8 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7