[PATCH] Btrfs: don't allocate chunks as aggressively V2

Because the ENOSPC code over reserves super aggressively we end up allocating chunks way more often than we should. For example with my fs_mark tests on a 2gb fs I can end up reserved 1gb just for metadata, when only 34mb of that is being used. So instead check to see if the amount of space actua

Re: [patch 2/4] Add an option to show ISO, binary or raw bytes counts using df.

On Mon, Oct 18, 2010 at 09:21:56AM +0100, Frank Kingswood wrote: > On 17/10/10 19:26, hugo-l...@carfax.org.uk wrote: >> Change btrfs filesystem df to allow the user to control the scales >> used for sizes in the output. >> >> Index: btrfs-progs-unstable/btrfs.c >> ==

Re: [PATCH 3/4] Btrfs: don't allocate chunks as aggressively

On Fri, Oct 15, 2010 at 05:28:34PM -0400, Josef Bacik wrote: > Because the ENOSPC code over reserves super aggressively we end up allocating > chunks way more often than we should. For example with my fs_mark tests on a > 2gb fs I can end up reserved 1gb just for metadata, when only 34mb of that i

[RFC] Allow to exec "btrfs subvolume delete" by a non root user

Hi all like my previous patch, this one allow to remove a subvolume by an ordinary user. Instead of adding this capability to the rmdir(2) syscall, I update the BTRFS_IOC_SNAP_DESTROY ioctl, relaxing the rules to be execute. The checks are the ones performed by the rmdir(2) syscall. So a subvolu

IOCTL #21 could also wait for btrfs_run_delayed_iputs

That's the other thing the cleaner_kthread does; conceivably some new delayed iputs could get queued during snapshot deletions. Thoughts? -- "In one instance, a rai being transported by canoe was accidentally dropped and sunk to the sea floor. Although it was never seen again, everyone agreed th

newbie question about struct btrfs_dir_item *btrfs_match_dir_item_name

reading, in dir-item.c, the code in struct btrfs_dir_item *btrfs_match_dir_item_name (...) I am a little surprised to see an O(n) iterative name comparison check instead of something that would efficiently support directories with lots of items in them. Is this function a fall-back if a O(1) table

R: [patch 0/4] Size reporting of btrfs tool

Hi Hugo, please, remember to update the manpage also. Regards G.Baroncelli >Messaggio originale >Da: hugo-l...@carfax.org.uk >Data: 17/10/2010 20.26 >A: >Ogg: [patch 0/4] Size reporting of btrfs tool > >While playing around with resizing volumes recently, I realised >that I didn't know

Re: the idea for improving the performance of b-tree search

On Mon, 18 Oct 2010 10:41:41 +0800, Shaohua Li wrote: Hi Miao& Chris, On Wed, Oct 13, 2010 at 05:00:56PM +0800, Miao Xie wrote: When I investigated the performance problem of file creation/deletion, I found btrfs spends lots of time in the b-tree search, so I consider whether we can use the lat

Re: [patch 2/4] Add an option to show ISO, binary or raw bytes counts using df.

On 17/10/10 19:26, hugo-l...@carfax.org.uk wrote: Change btrfs filesystem df to allow the user to control the scales used for sizes in the output. Index: btrfs-progs-unstable/btrfs.c === --- btrfs-progs-unstable.orig/btrfs.c 2010-