This RFC patch is intended to make our extent state code more rcu friendly.
o Since IO related extents in the tree will not be merged or changed,
we can safely clear the extents's lock flags at endio time.
o After clearing flags, we will merge the adjacent extents when their states
are equal,
On Wed, Feb 15, 2012 at 07:03:49AM +0100, Timo Nentwig wrote:
>
>
> On Tue, 14 Feb 2012, Chris Mason wrote:
>
> >Ok, 3.2 shouldn't have done this. Was this an external drive? What
> >else do you have on the system?
>
> Nothing special actually. Standard arch linux with virtualbox kernel modul
On Sun, 2012-02-12 at 16:14 -0800, Marc MERLIN wrote:
> Considering that I have a fairly new crucial 256GB SDD, I'm going to assume
> that this bit applies to me:
> "On the other side, TRIM is usually overrated. Drive itself should keep good
> performance even without TRIM, either by using internal
On Wed, Feb 15, 2012 at 01:43:02PM +0800, Anand Jain wrote:
>
> Hi Xin / Hugo,
> I am referring to
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
>
> has miss match parameter list for list_subvols
> --
> # cd btrfs-progs
> # egrep list_subvols *
> btrfs_cmds.
On Wed, Feb 15, 2012 at 10:42:43AM -0500, Calvin Walton wrote:
> On Sun, 2012-02-12 at 16:14 -0800, Marc MERLIN wrote:
> > Considering that I have a fairly new crucial 256GB SDD, I'm going to assume
> > that this bit applies to me:
> > "On the other side, TRIM is usually overrated. Drive itself sho
On Wed, Feb 15, 2012 at 08:55:40AM -0800, Marc MERLIN wrote:
> https://btrfs.wiki.kernel.org/articles/g/o/t/Gotchas.html
> still states 'btrfs volumes on top of dm-crypt block devices (and possibly
> LVM) require write-caching to be turned off on the underlying HDD. Failing
> to do so, in the event
On Tue, Feb 14, 2012 at 1:47 PM, Hugo Chevrain wrote:
>>
>> Are you sure about these figures ? the difference seems too large. It's
> almost
>> unbelievable.
>>
>> --
>
> You should not,
> Mark Ruijter found the same for LessFS (http://www.lessfs.com/wordpress/?
> p=688) and there is also such fin
The second link is broken, just remove scribe. from it.
https://twitter.com/#!/otisg/status/148848850914902016
It causes a cross-domain error, not sure why he could see it though.
On Wednesday, February 15, 2012 9:23:37 AM, Kok, Auke-jan H wrote:
On Tue, Feb 14, 2012 at 1:47 PM, Hugo Chevrain
I've been trying to test the snappy compression patches, but I'm
getting corruptions when trying to use snappy as built on my system.
I'm checking out the Linux 3.2.6 kernel, merging that with the latest
'for-linus' branch on Chris Mason's kernel.org repo, and then
integrating the snappy and lz4 p
Mitch Harder posted on Wed, 15 Feb 2012 16:46:00 -0600 as excerpted:
> I've been trying to test the snappy compression patches, but I'm getting
> corruptions when trying to use snappy as built on my system.
>
> I'm checking out the Linux 3.2.6 kernel, merging that with the latest
> 'for-linus' br
On Wed, Feb 15, 2012 at 5:03 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Mitch Harder posted on Wed, 15 Feb 2012 16:46:00 -0600 as excerpted:
>
>> I've been trying to test the snappy compression patches, but I'm getting
>> corruptions when trying to use snappy as built on my system.
>>
>> I'm checki
This patch adds the check on the return value of extent_io_ops.
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/extent_io.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index fcf77e1..a84621f 100644
--- a/fs/btrfs/e
Mitch Harder wrote:
> I've been trying to test the snappy compression patches, but I'm
> getting corruptions when trying to use snappy as built on my system.
>
> I'm checking out the Linux 3.2.6 kernel, merging that with the latest
> 'for-linus' branch on Chris Mason's kernel.org repo, and then
>
On Monday 13 February 2012 11:14:00 Marc MERLIN wrote:
> I knew that it created some security problems but I had not yet
> found the page you just gave, which effectively states that TRIM
> isn't actually that big a win on recent SSDs (I thought it was
> actually pretty important to use it on them
When I ran xfstests circularly on a auto-defragment btrfs, the deadlock
happened.
Steps to reproduce:
[tty0]
# export MOUNT_OPTIONS="-o autodefrag"
# export TEST_DEV=
# export TEST_DIR=
# export SCRATCH_DEV=
# export SCRATCH_MNT=
# while [ 1 ]
> do
> ./check 091 127 263
> sleep 1
> done
This patch corrects error checking of lookup_extent_mapping().
Signed-off-by: Tsutomu Itoh
---
fs/btrfs/compression.c |2 ++
fs/btrfs/extent_io.c |2 +-
fs/btrfs/volumes.c |2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/compression.c b/fs/btrfs/co
16 matches
Mail list logo