My reworking of file.c left a few memory leaks, this patch fixes these up.
Really these are places where before the rework we just BUG()'ed anyway, so it's
not that bad :). Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/file.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
d
Since we alloc/free free space entries a whole lot, lets use a slab to keep
track of them. This makes some of my tests slightly faster. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/ctree.h|1 +
fs/btrfs/free-space-cache.c | 38 --
fs/btr
Excerpts from Tsutomu Itoh's message of 2011-01-21 01:06:29 -0500:
> (2011/01/21 8:47), Tsutomu Itoh wrote:
> > (2011/01/21 1:09), Josef Bacik wrote:
> >> I'd rather we go through and have these things return an error than do a
> >> BUG_ON(). We're moving towards a more stable BTRFS, not one that
Got a report of a box panicing because we got a NULL eb in read_extent_buffer.
His fs was borked and btrfs_search_path returned EIO, but we don't check for
errors so the box paniced. Yes I know this will just make something higher up
the stack panic, but that's a problem for future Josef. Thanks,
On Friday, January 28, 2011 04:47:21 pm Maria Wikström wrote:
> fre 2011-01-28 klockan 03:54 +0100 skrev Johannes Hirte:
> > On Friday 28 January 2011 02:26:43 Zhong, Xin wrote:
> > > Please try the fix in below link:
> > > http://www.spinics.net/lists/linux-btrfs/msg08051.html
> > >
> > > Thanks
On 01/12/2011 07:44 AM, Dave Chinner wrote:
On Tue, Jan 11, 2011 at 04:13:42PM -0500, Lawrence Greenfield wrote:
On Tue, Nov 9, 2010 at 6:40 PM, Dave Chinner wrote:
The historical reason for such behaviour existing in XFS was that in
1997 the CPU and IO latency cost of unwritten extent convers
fre 2011-01-28 klockan 03:54 +0100 skrev Johannes Hirte:
> On Friday 28 January 2011 02:26:43 Zhong, Xin wrote:
> > Please try the fix in below link:
> > http://www.spinics.net/lists/linux-btrfs/msg08051.html
> >
> > Thanks!
>
> This doesn't fix it for me. At least there is a difference. Whereas
On 28.01.2011 14:45, Josef Bacik wrote:
It's not a problem, it just means that the cache is being discarded, which is
what is supposed to happen. You probably ran out of space or one of the other
corner cases where we can't write out the space cache. Thanks,
FYI, there is plenty of free space
On Fri, Jan 28, 2011 at 02:56:24PM +0100, Tomasz Chmielewski wrote:
> On 28.01.2011 14:45, Josef Bacik wrote:
>> It's not a problem, it just means that the cache is being discarded, which is
>> what is supposed to happen. You probably ran out of space or one of the
>> other
>> corner cases where
On Fri, Jan 28, 2011 at 10:59:56AM +0100, Tomasz Chmielewski wrote:
> Not sure if the:
>
> btrfs: free space inode generation (0) did not match free space cache
> generation
>
> is supposed to be fixed in 2.6.38-rc2?
>
It's not a problem, it just means that the cache is being discarded, which
Not sure if the:
btrfs: free space inode generation (0) did not match free space cache generation
is supposed to be fixed in 2.6.38-rc2?
I'm getting such entries in dmesg:
[12638.713154] device fsid 1142843480ad2d13-4bdc742fd9b1f7b0 devid 1 transid
3501 /dev/sdb4
[12638.713528] btrfs: force z
11 matches
Mail list logo
