On Tue, Aug 30, 2011 at 11:29 PM, Dave Chinner wrote:
> On Tue, Aug 30, 2011 at 06:17:02PM -0700, Sunil Mushran wrote:
>> Instead
>> we should let the fs weigh the cost of providing accurate information
>> with the possible gain in performance.
>>
>> Data:
>> A range in a file that could contain s
On 8/30/2011 8:29 PM, Dave Chinner wrote:
And that's -exactly- the ambiguous, vague definition that has raised
all these questions in the first place. I was in doubt about whether
unwritten extents can be considered a hole, and by your definition
that means it should be data. But Andreas seems to
Hello,
While going through the mkfs.c, I noticed there is an issue for label
length checking, mkfs.btrfs will crashed if the label length exceeding
255 bytes, it's easy to triggered that out as below:
jeff@pibroch:~/opensource/btrfs-progs$ sudo ./mkfs.btrfs -L `perl -e
'print "A"x256'` /usr/
On Wed, 31 Aug 2011, Dave Chinner wrote:
On Tue, Aug 30, 2011 at 06:17:02PM -0700, Sunil Mushran wrote:
On 08/25/2011 06:35 PM, Dave Chinner wrote:
Agreed, that's the way I'd interpret it, too. So perhaps we need to
ensure that this interpretation is actually tested by this test?
How about so
On Tue, Aug 30, 2011 at 06:17:02PM -0700, Sunil Mushran wrote:
> On 08/25/2011 06:35 PM, Dave Chinner wrote:
> >Agreed, that's the way I'd interpret it, too. So perhaps we need to
> >ensure that this interpretation is actually tested by this test?
> >
> >How about some definitions to work by:
> >
>
On 08/25/2011 06:35 PM, Dave Chinner wrote:
Agreed, that's the way I'd interpret it, too. So perhaps we need to
ensure that this interpretation is actually tested by this test?
How about some definitions to work by:
Data: a range of the file that contains valid data, regardless of
whether it ex
On Mon, Aug 22, 2011 at 07:56:31PM +0200, Marco Stornelli wrote:
> Il 22/08/2011 17:57, Sunil Mushran ha scritto:
> >>>Any proposal that differentiates between holes is wrong. It should not
> >>>matter where the hole is.
> >>>
> >>>Think of it from the usage-pov.
> >>>
> >>>doff = 0;
> >>>while ((d
> About the second one:
>
> > ==The Second Issue (aka "The Busy Looping sync()" case) ==
> > The box is different from first, so conditions are a bit different.
> > - /dev/root on / type btrfs (rw,noatime,autodefrag)
> > (note autodefrag!)
> > - 15% full 594GB filesystem (usual nonmixed mode)
>
> On 08/30/2011 03:40 PM, Josef Bacik wrote:
> > On 08/30/2011 03:31 PM, Sergei Trofimovich wrote:
> >> On Tue, 30 Aug 2011 14:02:37 -0400 Josef Bacik
> >> wrote:
> >>
> >>> On 08/30/2011 12:53 PM, Sergei Trofimovich wrote:
> > Running 'sync' program after the load does not finish and
> >
On 08/30/2011 03:40 PM, Josef Bacik wrote:
> On 08/30/2011 03:31 PM, Sergei Trofimovich wrote:
>> On Tue, 30 Aug 2011 14:02:37 -0400 Josef Bacik
>> wrote:
>>
>>> On 08/30/2011 12:53 PM, Sergei Trofimovich wrote:
> Running 'sync' program after the load does not finish and
> eats 100%CPU bus
It's not enough to just search the commit root, since we could be cow'ing the
very block we need to search through, which would mean that its locked and we'll
still deadlock. So use path->skip_locking as well. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/file-item.c |4 +++-
1 files cha
On 08/30/2011 03:31 PM, Sergei Trofimovich wrote:
> On Tue, 30 Aug 2011 14:02:37 -0400 Josef Bacik
> wrote:
>
>> On 08/30/2011 12:53 PM, Sergei Trofimovich wrote:
Running 'sync' program after the load does not finish and
eats 100%CPU busy-waiting for something in kernel.
It's
On Tue, 30 Aug 2011 14:02:37 -0400
Josef Bacik wrote:
> On 08/30/2011 12:53 PM, Sergei Trofimovich wrote:
> >> Running 'sync' program after the load does not finish and eats
> >> 100%CPU busy-waiting for something in kernel.
> >>
> >> It's easy to reproduce hang with patch for me. I just run
>
On 08/30/2011 12:53 PM, Sergei Trofimovich wrote:
>> Running 'sync' program after the load does not finish and eats
>> 100%CPU busy-waiting for something in kernel.
>>
>> It's easy to reproduce hang with patch for me. I just run
>> liferea and sync after it. Without patch I haven't managed to
>>
On 08/27/2011 01:30 AM, Marco Stornelli wrote:
Il 26/08/2011 16:41, Zach Brown ha scritto:
Hole: a range of the file that contains no data or is made up
entirely of NULL (zero) data. Holes include preallocated ranges of
files that have not had actual data written to them.
No for me. A hole i
> Running 'sync' program after the load does not finish and eats 100%CPU
> busy-waiting for something in kernel.
>
> It's easy to reproduce hang with patch for me. I just run liferea and sync
> after it. Without patch I haven't managed to hang btrfs up.
And I think it's another btrfs bug. I've ma
The only thing that we need to have a trans handle for is in
reserve_metadata_bytes and thats to know how much flushing we can do. So
instead of passing it around, just check current->journal_info for a
trans_handle so we know if we can commit a transaction to try and free up space
or not. Thanks
Since the durable block rsv stuff has been killed there is no need to get the
block_rsv in btrfs_free_tree_block anymore.
Signed-off-by: Josef Bacik
---
fs/btrfs/extent-tree.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tre
The alloc warnings everybody has been seeing is because we have been reserving
space for csums, but we weren't actually using that space. So make
get_block_rsv() return the trans->block_rsv if we're modifying the csum root.
Also set the trans->block_rsv to NULL so that if we modify the csum root w
Since free space inodes now use normal checksumming we need to make sure to
account for their metadata use. So reserve metadata space, and then if we fail
to write out the metadata we can just release it, otherwise it will be freed up
when the io completes. Thanks,
Signed-off-by: Josef Bacik
--
In moving some enospc stuff around I noticed that when we unmount we are often
evicting the free space cache inodes before we do our last commit. This isn't
bad, but it makes us constantly have to re-read the inodes back. So instead
don't evict the cache until after we do our last commit, this wi
On Tue, 2011-08-30 at 14:27 +0800, Miao Xie wrote:
> On mon, 29 Aug 2011 02:45:07 +0100, Maciej Marcin Piechotka wrote:
> > I receive the bug when I try to snapshot from fcron:
> >
> > 2011-08-29T02:00:46.529238+01:00 picard kernel: [ 4155.76]
> > [ cut here ]
> > 2011-
> There was once a similar thread about this issue; unfortunately, without any
> constructive answers:
>
> http://thread.gmane.org/gmane.comp.file-systems.btrfs/10840
I believe sync does a transaction commit every time.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
t
23 matches
Mail list logo
