Hi Miao,
thank you for your comments.
After some additional testing, few more observations:
# I see that only the OOM-fix patch was included in "for-linus" pull
request, but the rest of the patches are in btrfs-next. I hope they
will also make it into "for-linus" soon.
# for now, I have commente
On thu, 24 Jan 2013 18:20:06 +0200, Alex Lyakas wrote:
>>> - Is there something that user-space can do to avoid flushing the
>>> delalloc during snap-commit? For example, if the user-space stops the
>>> IO and does a normal commit, this will not call
>>> btrfs_start_delalloc_inodes(), but this shou
Hi Miao,
On Thu, Jan 24, 2013 at 4:14 AM, Miao Xie wrote:
> On wed, 23 Jan 2013 19:02:30 +0200, Alex Lyakas wrote:
>> Hi Miao,
>> I have tested your patch, and the two discussed issues (OOM and
>> handling the same inode more than once) are solved with it.
>>
>> However, snap creation under IO s
On wed, 23 Jan 2013 19:02:30 +0200, Alex Lyakas wrote:
> Hi Miao,
> I have tested your patch, and the two discussed issues (OOM and
> handling the same inode more than once) are solved with it.
>
> However, snap creation under IO still takes 5-10 minutes for me.
> Basically, now the situation is
Hi Miao,
I have tested your patch, and the two discussed issues (OOM and
handling the same inode more than once) are solved with it.
However, snap creation under IO still takes 5-10 minutes for me.
Basically, now the situation is similar to kernel 3.6, before your
change to push the work to the f
On Wed, 23 Jan 2013 17:52:14 +0800, Liu Bo wrote:
> On Wed, Jan 23, 2013 at 04:58:27PM +0800, Miao Xie wrote:
>> On wed, 23 Jan 2013 16:17:53 +0800, Liu Bo wrote:
>>> On Wed, Jan 23, 2013 at 02:33:27PM +0800, Miao Xie wrote:
On wed, 23 Jan 2013 14:06:21 +0800, Liu Bo wrote:
> On Wed, Jan 2
On Wed, Jan 23, 2013 at 04:58:27PM +0800, Miao Xie wrote:
> On wed, 23 Jan 2013 16:17:53 +0800, Liu Bo wrote:
> > On Wed, Jan 23, 2013 at 02:33:27PM +0800, Miao Xie wrote:
> >> On wed, 23 Jan 2013 14:06:21 +0800, Liu Bo wrote:
> >>> On Wed, Jan 23, 2013 at 12:44:49PM +0800, Miao Xie wrote:
> N
Hi Miao,
thank you for addressing the issue. I will try out this 5/5 patchset
and let you know what I see. I will apply it on top of latest
for-linus branch.
Thanks,
Alex.
On Wed, Jan 23, 2013 at 10:58 AM, Miao Xie wrote:
> On wed, 23 Jan 2013 16:17:53 +0800, Liu Bo wrote:
>> On Wed, Jan 23, 20
On wed, 23 Jan 2013 16:17:53 +0800, Liu Bo wrote:
> On Wed, Jan 23, 2013 at 02:33:27PM +0800, Miao Xie wrote:
>> On wed, 23 Jan 2013 14:06:21 +0800, Liu Bo wrote:
>>> On Wed, Jan 23, 2013 at 12:44:49PM +0800, Miao Xie wrote:
No, we can't. The other tasks which flush the delalloc data may remov
On Wed, Jan 23, 2013 at 02:33:27PM +0800, Miao Xie wrote:
> On wed, 23 Jan 2013 14:06:21 +0800, Liu Bo wrote:
> > On Wed, Jan 23, 2013 at 12:44:49PM +0800, Miao Xie wrote:
> >> No, we can't. The other tasks which flush the delalloc data may remove the
> >> inode
> >> from the delalloc list/splice
On wed, 23 Jan 2013 14:06:21 +0800, Liu Bo wrote:
> On Wed, Jan 23, 2013 at 12:44:49PM +0800, Miao Xie wrote:
>> No, we can't. The other tasks which flush the delalloc data may remove the
>> inode
>> from the delalloc list/splice list. If we release the lock, we will meet the
>> race
>> between l
On Wed, Jan 23, 2013 at 12:44:49PM +0800, Miao Xie wrote:
> No, we can't. The other tasks which flush the delalloc data may remove the
> inode
> from the delalloc list/splice list. If we release the lock, we will meet the
> race
> between list traversing and list_del().
OK, then please merge pat
On wed, 23 Jan 2013 11:56:55 +0800, Liu Bo wrote:
> On Wed, Jan 23, 2013 at 10:54:39AM +0800, Miao Xie wrote:
>> On Tue, 22 Jan 2013 22:24:15 +0800, Liu Bo wrote:
>>> On Tue, Jan 22, 2013 at 06:49:00PM +0800, Miao Xie wrote:
btrfs_start_delalloc_inodes() locks the delalloc_inodes list, fe
On Wed, Jan 23, 2013 at 10:54:39AM +0800, Miao Xie wrote:
> On Tue, 22 Jan 2013 22:24:15 +0800, Liu Bo wrote:
> > On Tue, Jan 22, 2013 at 06:49:00PM +0800, Miao Xie wrote:
> >> btrfs_start_delalloc_inodes() locks the delalloc_inodes list, fetches the
> >> first inode, unlocks the list, triggers btr
On Tue, 22 Jan 2013 22:24:15 +0800, Liu Bo wrote:
> On Tue, Jan 22, 2013 at 06:49:00PM +0800, Miao Xie wrote:
>> btrfs_start_delalloc_inodes() locks the delalloc_inodes list, fetches the
>> first inode, unlocks the list, triggers btrfs_alloc_delalloc_work/
>> btrfs_queue_worker for this inode, and
On Tue, Jan 22, 2013 at 06:49:00PM +0800, Miao Xie wrote:
> btrfs_start_delalloc_inodes() 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 it locks the list, checks the
> head of the list a
btrfs_start_delalloc_inodes() 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 it locks the list, checks the
head of the list again. But because we don't delete the first inode that it
deals wi
17 matches
Mail list logo
