similar to: [PATCH 1/2] Btrfs: remove bad fsync transaction check

Displaying 20 results from an estimated 200 matches similar to: "[PATCH 1/2] Btrfs: remove bad fsync transaction check"

2008 Dec 11
0
[PATCH] btrfs: mnt_drop_write in ioctl_trans_end
Add missing mnt_drop_write to match the mnt_want_write in btrfs_ioctl_trans_start. Signed-off-by: Sage Weil <sage@newdream.net> --- fs/btrfs/ioctl.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index 6228b69..69c4a07 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -1059,6 +1059,8 @@ long btrfs_ioctl_trans_end(struct
2009 Nov 10
12
[RFC] big fat transaction ioctl
Hi all, This is an alternative approach to atomic user transactions for btrfs. The old start/end ioctls suffer from some basic limitations, namely - We can''t properly reserve space ahead of time to avoid ENOSPC part way through the transaction, and - The process may die (seg fault, SIGKILL) part way through the transaction. Currently when that happens the partial transaction will
2013 Jan 21
1
btrfs_start_delalloc_inodes livelocks when creating snapshot under IO
Greetings all, I see the following issue during snap creation under IO: Transaction commit calls btrfs_start_delalloc_inodes() that locks the delalloc_inodes list, fetches the first inode, unlocks the list, triggers btrfs_alloc_delalloc_work/btrfs_queue_worker for this inode and then locks the list again. Then it checks the head of the list again. In my case, this is always exactly the same
2009 Aug 24
0
[PATCH] Btrfs: proper metadata -ENOSPC handling
This patch finally gives us full proper -ENOSPC handling for btrfs. Now whenever you do a btrfs_start_transaction, you must specify the number of items you are planning to add/delete/modify. The worst case number of blocks that could be modified by changing that number of items will be calculated and checked against the amount of free space in the space_info where the root you are modifying
2010 Mar 22
5
[PATCH 0/5] asynchronous commit, snapshot ponies
Hi everyone, This patchset is the latest approach I''m using for the Ceph storage daemon to keep track of which data has safely committed to disk. The basic idea is to not use the (problematic) user transaction ioctls at all. Instead, the daemon quiesces its own write requests, initiates an async snapshot, and then continues. The snapshot approach is nice because it provides rollback.
2008 Aug 30
0
[PATCH] btrfs: remove unused function btrfs_ilookup
btrfs_ilookup is unused, which is good because a normal filesystem should never have to use ilookup anyway. Remove it. Signed-off-by: Christoph Hellwig <hch@lst.de> Index: btrfs-unstable/ctree.h =================================================================== --- btrfs-unstable.orig/ctree.h 2008-08-30 11:08:58.000000000 -0300 +++ btrfs-unstable/ctree.h 2008-08-30 11:09:10.000000000
2007 Aug 09
1
[RFC] All my fsync changes
Hello, Ok here are all my fsync changes, including the fix for the put_transaction stuff that I posted earlier. I figure it'll be easier to just commit it as one thing then each individual peice. The additional thing that I did was add a radix tree that tracks the current outstanding transactions. I also added a field to the in memory btrfs inode that keeps track of the last transaction
2010 Dec 14
0
[PATCH] BTRFS_IOC_TREE_SEARCH: store and use the last key found
Hi all, following the thread about the BTRFS_IOC_TREE_SEARCH ioctl [1], I made a patch which try to address the problem of restarting the ioctl. In the current solution is the application during the restart of the search to fill the min_* fields in the "struct btrfs_ioctl_search_key". In general the values set are the last one returned "+1". But doing so we reduce the
2010 Oct 25
14
[PATCH 0/6] Btrfs commit fixes, async subvol operations
Hi Chris, This is the extent of my current queue of Btrfs snapshot/subvol/commit stuff. Most of these were posted several months ago. Can be sent upstream during this merge window? Not having this functionality is becoming a bit of a roadblock for our efforts to keep the Ceph data in a consistent state. These patches are also available from
2009 Jan 24
2
[PATCH] btrfs: flushoncommit mount option
Hi Chris- Here''s a simpler version of the patch that drops the unrelated sync_fs stuff. thanks- sage The ''flushoncommit'' mount option forces any data dirtied by a write in a prior transaction to commit as part of the current commit. This makes the committed state a fully consistent view of the file system from the application''s perspective (i.e., it
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
2010 Nov 18
9
Interesting problem with write data.
Hi, Recently, I made a btrfs to use. And I met slowness problem. Trying to diag it. I found this: 1. dd if=/dev/zero of=test count=1024 bs=1MB This is fast, at about 25MB/s, and reasonable iowait. 2. dd if=/dev/zero of=test count=1 bs=1GB This is pretty slow, at about 1.5MB/s, and 90%+ iowait, constantly. May I know why it works like this? Thanks. -- To unsubscribe from this list: send the
2010 Oct 26
0
[PATCH v2] Btrfs: fix deadlock in btrfs_commit_transaction
We calculate timeout (either 1 or MAX_SCHEDULE_TIMEOUT) based on whether num_writers > 1 or should_grow at the top of the loop. Then, much much later, we wait for that timeout if either num_writers or should_grow is true. However, it''s possible for a racing process (calling btrfs_end_transaction()) to decrement num_writers such that we wait forever instead of for 1. Fix this by
2013 Oct 28
0
[PATCH] Btrfs: make sure the delalloc workers actually flush compressed writes
When using delalloc workers in a non-waiting way (like for enospc handling) we can end up not actually waiting for the dirty pages to be started if we have compression. We need to add an extra filemap flush to make sure any async extents that have started are actually moved along before returning. Thanks, Signed-off-by: Josef Bacik <jbacik@fusionio.com> --- fs/btrfs/inode.c | 18
2012 Aug 24
4
[PATCH] Btrfs: pass lockdep rwsem metadata to async commit transaction
The freeze rwsem is taken by sb_start_intwrite() and dropped during the commit_ or end_transaction(). In the async case, that happens in a worker thread. Tell lockdep the calling thread is releasing ownership of the rwsem and the async thread is picking it up. Josef and I worked out a more complicated solution that made the async commit thread join and potentially get a later transaction, but
2006 Feb 23
1
Ext3: Ordered : Fsync question
Does Fsync of a file on a ext3 fs mounted with "ordered" option(the default) result in flush the dirty data buffers in the fs that correspond to previous transactions. In other words, if I keep writing to file1 (lots of data), log something to file2, keep fsyncing file2 after every write - does this mean file1 data would be committed by fsyncs on file2. Please copy me on your replies
2004 Feb 13
1
fsync in ext3: A question
Hi, I have a question on fsync() and ext3's journaling modes. Assume that I call fsync(fd) on a file. If that file is in 'data=journal' mode, would the fsync() return once the data gets safely into the journal ? On the other hand, if that file is in 'data=writeback' mode, would the fsync() return only when the data gets safely into its actual location ? Any help is
2003 Feb 04
1
Quick fsync question
If I want to make sure a file has really been deleted do I have to: 1. fsync the file 2. fsync the directory the file is in 3. both? Much thanks. -- Ben Escoto
2003 Feb 24
0
fsync() and data=journal behaviour
I'm currently looking at the behaviour of various Linux filesystems as backends for the Cyrus IMAP server. Like many mail applications, Cyrus makes heavy use of the fsync() system call to ensure that data has hit stable storage before it acknowledges receipt of messages. At the moment fsync() appears to introduce lots of synchronous I/O as data is flushed all the way through to the filesystem
2010 Apr 11
1
Re: Poor interactive performance with I/O loads with fsync()ing
On Sun, 11 Apr 2010 18:03:00 +0300, Avi Kivity <avi@redhat.com> wrote: > On 04/09/2010 05:56 PM, Ben Gamari wrote: > > On Mon, 29 Mar 2010 00:08:58 +0200, Andi Kleen<andi@firstfloor.org> wrote: > > > >> Ben Gamari<bgamari.foss@gmail.com> writes: > >> ext4/XFS/JFS/btrfs should be better in this regard > >> > >> >