search for: btrfs_release_file

Displaying 5 results from an estimated 5 matches for "btrfs_release_file".

2010 Mar 15
1
[PATCH 1/2] Btrfs: remove bad fsync transaction check
This check for a user transaction is a bogus: fsync() with an open user transaction is verboten. If the caller is the same process who started a user transaction, and this is a different file, we will deadlock. If it''s the same file, this check means we won''t deadlock, but the transaction will be prematurely closed out. Any user transaction ioctl users should be careful to
2009 Nov 12
0
[PATCH 03/12] Btrfs: Rewrite btrfs_drop_extents
...+int btrfs_drop_extents(struct btrfs_trans_handle *trans, struct inode *inode, + u64 start, u64 end, u64 *hint_byte, int drop_cache); int btrfs_mark_extent_written(struct btrfs_trans_handle *trans, - struct btrfs_root *root, struct inode *inode, u64 start, u64 end); int btrfs_release_file(struct inode *inode, struct file *file); diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 4599113..a4a6d2c 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -265,319 +265,247 @@ int btrfs_drop_extent_cache(struct inode *inode, u64 start, u64 end, * If an extent intersects the range but...
2010 May 07
6
[PATCH 1/5] fs: allow short direct-io reads to be completed via buffered IO V2
V1->V2: Check to see if our current ppos is >= i_size after a short DIO read, just in case it was actually a short read and we need to just return. This is similar to what already happens in the write case. If we have a short read while doing O_DIRECT, instead of just returning, fallthrough and try to read the rest via buffered IO. BTRFS needs this because if we encounter a compressed or
2011 Jun 21
19
[GIT PULL v3] Btrfs: improve write ahead log with sub transaction
I''ve been working to try to improve the write-ahead log''s performance, and I found that the bottleneck addresses in the checksum items, especially when we want to make a random write on a large file, e.g a 4G file. Then a idea for this suggested by Chris is to use sub transaction ids and just to log the part of inode that had changed since either the last log commit or the last
2012 Apr 20
44
Ceph on btrfs 3.4rc
After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I''m still seeing is a warning that seems to occur from time to time: [87703.784552] ------------[ cut here ]------------ [87703.789759] WARNING: at fs/btrfs/inode.c:2103