From: Anand Jain anand.j...@oracle.com
Moved from hash method of determining the FS changes to the transaction
record id method
Signed-off-by: Anand Jain anand.j...@oracle.com
---
Makefile |2 +-
autosnap.c | 176 ++--
autosnap.h |
On Tue, Mar 06, 2012 at 05:30:23AM +, Duncan wrote:
Kai Ren posted on Mon, 05 Mar 2012 21:16:34 -0500 as excerpted:
I've run a little wired benchmark on comparing Btrfs v0.19 and XFS:
[snip description of test]
I monitor the number of disk read requests
#WriteRq
Am Tue, 28 Feb 2012 10:06:14 +0800
schrieb Liu Bo liubo2...@cn.fujitsu.com:
On 02/27/2012 09:29 PM, Johannes Hirte wrote:
Am Tue, 17 Jan 2012 17:51:59 +0800
schrieb Liu Bo liubo2...@cn.fujitsu.com:
I've kept hitting enospc warnings of global_rsv while running
defragment on files:
Hi All,
I've noticed today below WARN_ON from btrfs. Google shows hits in the
same place ([1] and [2]) but the path is different. It could happen
when svn checout or few rsyncs were running - now I'm not able to put
in correct timings. There's btrfs_item_offset() in backtrace and I
was not able
Hugo Mills posted on Tue, 06 Mar 2012 11:29:58 + as excerpted:
The in-memory buffer is simply the standard Linux block layer and FS
cache: When a piece of metadata is searched for, btrfs walks down the
relevant tree, loading each tree node (a 4k page) in turn, until it
finds the metadata.
On Thu, Nov 17, 2011 at 12:59 AM, Arnd Hannemann a...@arndnet.de wrote:
Am 14.11.2011 19:24, schrieb Arnd Hannemann:
Am 14.11.2011 15:57, schrieb Arnd Hannemann:
I'm using btrfs for my /usr/share/ partition and keep getting the following
error
while installing a debian package which should
