On Sun, 2021-01-10 at 13:08 +0100, Forza wrote:
>
> On 2021-01-10 12:52, David Woodhouse wrote:
> > I migrated a system to btrfs which was hosting virtual machins with
> > qemu.
> >
> > Using it without disabling copy-on-write was a mistake, of course, and
> &g
I migrated a system to btrfs which was hosting virtual machins with
qemu.
Using it without disabling copy-on-write was a mistake, of course, and
it became horribly fragmented and slow.
So I tried copying it to a new file... but it has actual *errors* too,
which I think are because it was using th
On Wed, 2011-07-20 at 04:44 -0400, Chris Mason wrote:
> Oh, the dirty little secret of loop devices is they don't actually write
> things to disk properly. They are not power off safe. But you can
> trigger this without a loop device, correct?
Yes. I would have liked to reproduce it last night
On Wed, 2011-06-22 at 12:09 -0400, Josef Bacik wrote:
> On 06/10/2011 05:52 PM, Marek Otahal wrote:
> > On Friday 10 of June 2011 16:52:36 Josef Bacik wrote:
> >> On 06/10/2011 02:43 PM, Marek Otahal wrote:
> >>> On Friday 10 of June 2011 15:33:20 Josef Bacik wrote:
> On 06/09/2011 10:06 PM, D
:1755: update_space_info: Assertion `!(found->total_bytes <
found->bytes_used)' failed.
I can mount it read-only though and read certain things out of it. But
when I boot from it, I hit the BUG().
--
David WoodhouseOpen Source Techn
On Wed, 2010-06-23 at 20:43 -0700, Daniel Taylor wrote:
> There is also the issue of btrfs over RAID (which I know is not
> entirely sensible, but which will happen).
Well, we could discourage that by merging the RAID support that's been
pending for a while but I suspect Chris is a bit busy r
btrfs-raid56.git/commitdiff/3885963f
http://git.infradead.org/users/dwmw2/btrfs-raid56.git/commitdiff/3de9680a
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
--
To unsubscribe from this list: send the l
On Mon, 2010-05-03 at 22:02 +0200, Roy Sigurd Karlsbakk wrote:
> Is raid[56] coming to btrfs? There was some talk about it a year back
> or so, but I haven't seen anything yet
Um, there was some talk about it about four days ago. You even
participated in that thread!
As it stands, it has the
lumes.c:3913 btrfs_map_bio+0x482/0x6c2 [btrfs]()
[] btrfs_map_bio+0x482/0x6c2 [btrfs]
[] __btree_submit_bio_done+0x16/0x18 [btrfs]
[] run_one_async_done+0x8d/0x92 [btrfs]
[] run_ordered_completions+0x73/0x
ot;Q":"D"),
+ i, this_bio,
+ this_bio->bi_bdev->bd_dev,
+ (u64)this_bio->bi_sector << 9);
+ schedule_bio(root, multi->stripes[i].dev, WRITE, this_bio);
+ }
+
+ /* Write the ori
rite size, weren't you?
I'm also going to do RAID50/60 support, and with hpa's help I'll extend
it to do RAID7/70 too -- but you're not waiting for that, are you?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
aid56.git
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
Mor
writing _everything_.
- Support for more than 2 redundant blocks per stripe (RAID[789] or
RAID6[³⁴⁵] or whatever we'll call it).
- RAID[56789]0 support.
- Clean up the discard support to do the right thing.
--
David WoodhouseOpen Source Techn
again:
em->start + (tmp + i) * map->stripe_len;
raid_map[(i+rot) % map->num_stripes] = RAID5_P_STRIPE;
- if (map->type & BTRFS_BLOCK_GROUP_RAID6)
+ if ((map->type >> 56) >= 2)
On Sat, 2009-07-18 at 13:04 -0700, Dan Williams wrote:
> On Sat, Jul 18, 2009 at 11:42 AM, David Woodhouse wrote:
> > On Sat, 18 Jul 2009, Dan Williams wrote:
> >> I was under the impression that btrfs wanted to leverage md's stripe
> >> handling logic as
On Sat, 18 Jul 2009, Dan Williams wrote:
On Sat, Jul 18, 2009 at 4:53 AM, David Woodhouse wrote:
On Fri, 2009-07-17 at 11:49 -0400, H. Peter Anvin wrote:
Cost, yes, of changing an on-disk format.
Personally, I don't care about that -- I'm utterly uninterested in the
legacy RA
like http://git.infradead.org/mtd-utils.git?a=blob;f=fec.c to start
with, and maybe hoping that someone cleverer will come up with something
better.
The less I have to deal with Galois Fields, the happier I'll be.
--
David WoodhouseOpen Source Technology Cent
, and failing the bio with
-EIO. But then we were using the stale buffers anyway. This patch fixes
a couple of places where we do that, and gives me a much saner failure
mode. There are probably other places which need a similar fix.
Signed-off-by: David Woodhouse
diff --git a/fs/btrfs/disk-io.c
On Sat, 2009-07-11 at 15:40 +0100, David Woodhouse wrote:
> On Sat, 2009-07-11 at 15:39 +0100, David Woodhouse wrote:
> > This is a preliminary attempt to add RAID5 and RAID6 support.
>
> Matching btrfs-progs patch...
And this makes it actually write the P and Q stripes...
These
On Mon, 2009-07-13 at 11:05 +0100, David Woodhouse wrote:
>
> This hack serves two purposes:
> - It does actually write parity (and RAID6 syndrome) blocks so that I
>can implement and test the recovery.
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 1f509ab..a23510b
superblock copies. So listing more blocks than we need
is actually OK.
With RAID[56] we're going to throw away an entire stripe for each block
we have to ignore, so we _are_ going to list blocks other than the
ones which actually contain the superblock.
Signed-off-by: David Woodhouse
---
fs/
ll do that when I have to unbreak it for RAID5 anyway.)
Signed-off-by: David Woodhouse
---
fs/btrfs/extent-tree.c | 25 +++--
1 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 1496925..d829ef3 100644
---
s_info->mapping_tree, WRITE,
bytenr, &map_length, &multi, 0);
if (!ret) {
struct btrfs_bio_stripe *stripe = multi->stripes;
--
1.6.2.5
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
We'll want to use these in btrfs too.
Signed-off-by: David Woodhouse
---
drivers/md/Kconfig |5 +-
drivers/md/Makefile | 76 -
lib/Kconfig |3 +
lib/Mak
27;t mess things up. Yan Zheng, is there any reason we
> shouldn't delete it?
I deleted it in my tree because it made my head hurt for RAID5:
http://git.infradead.org/users/dwmw2/btrfs-raid56.git?a=commitdiff;h=93562d49
--
David WoodhouseOpen Source Technology Cen
se actions failing.
But I don't believe we have yet implemented anything to let you
_replace_ a failed disk and recreate its original contents.
I had that on my TODO list for some time after I get the basic RAID[56]
operation working.
--
David WoodhouseOpen S
g free space in the stripe-set, if we can't manage that).
So hopefully most of this code can go away in the end -- although some
of it may be cannibalised to handle rebuilding after a disk replacement.
Signed-off-by: David Woodhouse
---
fs/btrfs/Kconfig |1 +
fs/bt
On Sat, 2009-07-11 at 15:39 +0100, David Woodhouse wrote:
> This is a preliminary attempt to add RAID5 and RAID6 support.
>
> So far it doesn't attempt to write or read the parity blocks -- it
> just
> lays the data blocks out as we want them, so it's effectively just
something, then let them both use it from there.
We do want to do full stripe writes to the RAID[56] parts, so we're
going to want to do something like falling back to RAID1 (or to a RAID5
chunk with smaller stripe length) for smaller allocations. That's
basically what
On Sat, 2009-07-11 at 15:39 +0100, David Woodhouse wrote:
> This is a preliminary attempt to add RAID5 and RAID6 support.
Matching btrfs-progs patch...
diff --git a/ctree.h b/ctree.h
index a9062ea..5b3c690 100644
--- a/ctree.h
+++ b/ctree.h
@@ -640,6 +640,8 @@ struct btrfs_csum_item {
#def
* map->num_stripes + i;
- }
- bytenr = chunk_start + stripe_nr * map->stripe_len;
+ } /* else if RAID[56], multiply by nr_data_stripes().
+ * Alternatively, just use rmap_len below instead of
+ * map
On Thu, 2009-07-09 at 23:57 +0100, David Woodhouse wrote:
> On Sat, 2009-01-03 at 23:33 +0800, Liu Hui wrote:
> > + /* Tell the block device(s) that the sectors can be discarded */
> > + ret = btrfs_map_block(&root->fs_info->mapping_tree, READ,
> > +
block(&root->fs_info->mapping_tree, WRITE,
bytenr, &map_length, &multi, 0);
if (!ret) {
struct btrfs_bio_stripe *stripe = multi->stripes;
--
David WoodhouseOpen Source Technology Centre
david.woodho...@int
27;t that READ be a WRITE, if we want to discard every stripe of a
RAID1 rather than only one of them?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
--
To unsubscribe from this list: send the l
ony refers to, in fact, on the basis that it can be done within an
initrd and doesn't have to live in the kernel.
Mount by UUID for other file systems is already handled by initrd; the
kernel can't do it for itself.
--
David WoodhouseOpen Source Technology C
On Sun, 2009-04-19 at 19:30 -0400, Chris Mason wrote:
> On Mon, 2009-04-20 at 00:19 +0100, David Woodhouse wrote:
> > On Sun, 2009-04-19 at 19:11 -0400, Chris Mason wrote:
> > > How does this enable the HW crc32c? Unless I'm missing something you're
> > > doin
ng Intel's CRC32C instruction can be
used where available.
Signed-off-by: Herbert Xu
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
--
To unsubscribe from this list: send the
and proper.
Signed-off-by: David Woodhouse
---
fs/btrfs/crc32c.h | 29 -
fs/btrfs/disk-io.c |4 ++--
fs/btrfs/extent-tree.c |1 -
fs/btrfs/hash.h|4 ++--
4 files changed, 4 insertions(+), 34 deletions(-)
delete mode 100644 fs/btrfs/crc3
y writing
zeroes instead of just issuing a discard command though. That doesn't
seem like a massively cunning plan.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
--
To unsubscribe f
e would be an
> ongoing maintenance cost
They were talking about 'restrict', not strict-aliasing. Where it can be
used, it's going to give you optimisations that strict-aliasing can't.
--
David WoodhouseOpen Source Technology Centre
david.woodho
ug, it would have been harmless to inline them all.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe l
have expected GCC to
get this particular case right.
- Have a similar policy of PR# or explanation for 'uninline' too.
I don't think we should just give up on GCC ever getting it right. That
way lies madness. As we've often found in the past.
--
Da
Signed-off-by: David Woodhouse
---
Lifted the first paragraphs of btrfs.txt straight from the wiki...
Documentation/filesystems/btrfs.txt | 92 +
fs/btrfs/COPYING| 356 ---
fs/btrfs/INSTALL| 48 -
3 files
have 'select LIBCRC32C', and the documentation on the
userspace utilities probably lives _with_ the userspace repo. Might be
worth adding a pointer to the userspace utilities though, in
Documentation/filesystems/btrfs.txt
I think you can drop your own copy of the GPL too.
--
David Woodho
just yet, but that doesn't mean it shouldn't be set up to
allow that to happen in future.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
--
To unsubscribe from this list: send the line "
On Thu, 2008-10-09 at 15:52 -0600, Eric Anopolsky wrote:
> On Thu, 2008-10-09 at 15:55 +0200, Christian Parpart wrote:
> > On Thursday 09 October 2008 12:45:06 David Woodhouse wrote:
> > > On Thu, 2008-10-09 at 04:20 +0200, Christian Parpart wrote:
> > > > this now
On Thu, 2008-10-09 at 04:20 +0200, Christian Parpart wrote:
> this now makes use of autoconf/automake/libtool suite,
Please, God, no.
I will personally buy a licence for GNU make for anyone who needs one.
--
David WoodhouseOpen Source Technology Centre
[EM
On Tue, 2008-08-19 at 15:49 +0100, David Woodhouse wrote:
> On Tue, 2008-08-19 at 07:54 -0400, Chris Mason wrote:
> >
> > > What if the parent inode actually _is_ inode #0x? Can
> > > that happen? In that case it would return zero, and I shouldn'
n the real root instead.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
---
Is the offset of (u64)-1 in btrfs_read_fs_root_no_name() correct?
And can we have subroots (with ino == parent ino) elsewhere, or only as
direct children of sb->s_root?
export.c | 13 -
1 fil
This allows version.h to be generated from either git or hg.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
---
version.sh | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/version.sh b/version.sh
index d7988bf..209b7d1 100644
--- a/version.sh
Using a 64-bit hash as the readdir cookie is just asking for trouble.
And gets it, when we try to export the file system by NFS.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
---
(Corresponding patch for btrfs-progs in the repo at
git://git.infradead.org/users/dwmw2/btrfs-progs-unstab
This disappeared when I removed the special case for '.' in btrfs_lookup()
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
---
super.c | 34 +++---
1 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/super.c b/super.c
index 55f4d00
ing zero is fine. And we shouldn't be
subtracting one from it to find the slot we want?
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
--
To unsubscribe from this list: send the line "unsu
ad locks. What were you doing at the time?
Just using CONFIG_DEBUG_PAGEALLOC and dirtying a bunch of pages from
different inodes seems enough. Another patch to add to my collection at
git.infradead.org/users/dwmw2/btrfs-kernel-unstable.git ...
From: David Woodhouse <[EMAIL PROTECTED]>
Date: T
't really seem like a useful thing to
do.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a me
On Mon, 2008-08-18 at 16:32 -0400, Chris Mason wrote:
> On Mon, 2008-08-18 at 21:20 +0100, David Woodhouse wrote:
> > On Mon, 2008-08-18 at 15:47 -0400, Chris Mason wrote:
> > > Lets pretend I had put in commments something like the code below.
> > > The important pa
amp;key, slot);
if (key.objectid != dir->i_ino || key.type != BTRFS_INODE_REF_KEY)
goto out;
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
--
To unsubscribe from this list: send the line &q
a deep subdirectory and reboot the
server, and it all works fine again when the server comes back.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
--
To unsubscribe from this list: send the line "unsubs
n the tree, not later.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [EMAIL PROTECTE
index, so it normally won't happen.
Ok, that's fine then. I've removed the WARN_ON() from the patch in my
git tree. This is what I have outstanding for you at
git://git.infradead.org/users/dwmw2/btrfs-kernel-unstable:
Balaji Rao (2):
Introduce btrfs_iget helper
NFS support for
On Mon, 2008-08-18 at 12:51 +0100, David Woodhouse wrote:
> The patch below works OK, but doesn't yet handle
> subvolumes -- it gives the same fsid for all subvolumes.
Is this the correct fix?
diff --git a/super.c b/super.c
index 6446ab7..55f4d00 100644
--- a/super.c
+++ b/super.
f_fsid field in
btrfs_statfs(). The patch below works OK, but doesn't yet handle
subvolumes -- it gives the same fsid for all subvolumes.
But then, since we're also returning the same {dev,ino#} for all
subvolumes, nfs exporting isn't the _only_ thing that's going to get
confuse
On Sun, 2008-08-17 at 15:17 +0100, David Woodhouse wrote:
> Subject: [PATCH] Remove special cases for "." and ".."
>
> We never get asked by the VFS to lookup either of them, and we can
> handle the readdir() case a lot more simply, too.
And a few other minor cle
On Sun, 2008-08-17 at 14:30 +0100, David Woodhouse wrote:
> I think we should just remove that code completely -- and remove the
> similar code from btrfs_real_readdir() while we're at it -- just use
> parent_ino(filp->f_path.dentry) instead. In _that_ case, we know the
>
next leaf, and
we treat that as an error instead of rewinding to the one we want. It's
just the same error, but in reverse.
Or am I missing something?
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporatio
t;." and ".." at
all. We haven't needed that since the 2.2 kernel, have we?
I think we should just remove that code completely -- and remove the
similar code from btrfs_real_readdir() while we're at it -- just use
parent_ino(filp->f_path.dentry) instead. In _that_ case, we k
On Sun, 2008-08-17 at 18:21 +0530, Balaji Rao wrote:
> On Sunday 17 August 2008 05:23:22 pm David Woodhouse wrote:
> > On Mon, 2008-07-21 at 02:01 +0530, Balaji Rao wrote:
> > > Here's an implementation of NFS support for btrfs. It does not work in
> > > one
cause btrfs_get_parent() is failing. In my case, it seems to be
because the 'if (slot >= nritems)' check is triggering -- both are set
to 14. I'm now trying to work out precisely what that means...
--
David WoodhouseOpen Source Technology Centre
[EM
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
---
Jens has just said he'll take the block parts of this; it's harmless in
older kernels without BIO_RW_DISCARD defined.
extent-tree.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
dif
() w/compat routine,
change fh_type, store parent's root object ID where needed]
Signed-off-by: Balaji Rao <[EMAIL PROTECTED]>
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
---
This replaces patch 2 of the sequence I sent out yesterday; the other
two patches remain
On Wed, 2008-08-13 at 10:07 +0100, David Woodhouse wrote:
> /* the inode and parent dir are two different roots */
> if (new && root != sub_root) {
> igrab(inode);
> sub
e and parent dir are two different roots */
if (new && root != sub_root) {
igrab(inode);
sub_root->inode = inode;
do_orphan = 1;
}
... should also be fine when the inode is unlocked, too.
--
Dav
On Tue, 2008-08-12 at 14:51 -0400, Christoph Hellwig wrote:
> On Tue, Aug 12, 2008 at 02:46:46PM +0100, David Woodhouse wrote:
> > +static inline struct dentry *d_obtain_alias(struct inode *inode)
> > +{
> > + struct dentry *d = d_alloc_anon(inode);
> > + if (!d)
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
---
inode.c | 104 +-
1 files changed, 102 insertions(+), 2 deletions(-)
diff --git a/inode.c b/inode.c
index 5344526..faa5543 100644
--- a/inode.c
+++ b/inode.c
@@ -1956,7 +
From: Balaji Rao <[EMAIL PROTECTED]>
This patch introduces a btrfs_iget helper to be used in NFS support.
Signed-off-by: Balaji Rao <[EMAIL PROTECTED]>
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
---
ctree.h |2
() w/compat.]
Signed-off-by: Balaji Rao <[EMAIL PROTECTED]>
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
---
Makefile |2 +-
compat.h | 10
export.c | 174 ++
export.h | 17 ++
super.c |2 +
5 files
On Fri, 2008-08-08 at 15:05 +0100, David Woodhouse wrote:
> On Fri, 2008-08-08 at 09:56 -0400, Chris Mason wrote:
> > So you mkfs ; dd large file ; rm large file ; look for discards?
> >
> > Try rm large file ; sync ; sync; look for discards
>
> Yeah, I did that. T
On Fri, 2008-08-08 at 09:56 -0400, Chris Mason wrote:
> So you mkfs ; dd large file ; rm large file ; look for discards?
>
> Try rm large file ; sync ; sync; look for discards
Yeah, I did that. The actual data extent isn't getting removed.
[EMAIL PROTECTED] /]# modprobe mtdram total_size=28
multi->stripes[i].physical
>> 9,
+min(map_length, num_bytes)
>> 9,
+NULL);
+ }
+ kfree(multi);
+ }
}
btrf
export it by NFS. But it's easy enough to copy it over.
Added to git.infradead.org/users/dwmw2/btrfs-kernel-unstable.git
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Wed, 6 Aug 2008 19:42:33 +0100
Subject: [PATCH] Implement our own copy of the nfsd readdir hack, for older
kernels
Sig
that for
the masochists^Wenterprise folks.
>From 6c5f1012ccb1bb8a55dc9e564db3ca15d893763b Mon Sep 17 00:00:00 2001
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Wed, 6 Aug 2008 15:54:51 +0100
Subject: [PATCH] Change TestSetPageLocked() to trylock_page()
Add backwards compatibility in c
On Thu, 2008-07-31 at 15:37 -0400, Chris Mason wrote:
> If you can reliably reproduce this, please try with the spin locks
> instead of rcu read locks. What were you doing at the time?
Just copying a bunch of files into it so that I could test NFS
readdirplus with the following:
http://gi
ld_rip+0x0/0x11
Code: de e8 15 d5 ff ff 4c 39 75 c0 74 1a 73 13 be d5 05 00 00 48 c7 c7 fc fd
3e a0 e8 1c c5 c5 e0 eb 05 4d 85 e4 75 a4 4d 85 ed 74 19 <49> 8b 45 08 48 ff c0
4c 39 f0 75 0a 41 f6 85 80 00 00 00 02 75
RIP [] end_bio_extent_writepage+0x1f4/0x29c [btrfs]
RSP
CR2: 8
load it and avoid it hitting a
BUG_ON() when it first tries to mount, I can perhaps move on to doing
something more useful with it... :)
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
--
To unsubscribe
On Tue, 2008-07-22 at 10:42 -0700, Zach Brown wrote:
> David Woodhouse wrote:
> > On Tue, 2008-07-22 at 13:03 -0400, Chris Mason wrote:
> >> Well, the test is there to make sure the caller is doing the right
> >> thing. Before we remove it, I'd like
ely nothing, and spin_trylock() _always_ returns 1.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body o
On uniprocessor kernels without spinlock debugging, spinlock operations
are all no-ops and spin_trylock() will always succeed.
These BUG_ON() sanity checks are effectively an unconditional BUG() in
that case.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/extent_m
On Tue, 2008-07-22 at 06:21 -0400, Chris Mason wrote:
> What kind of box is this? The current code should be fine on big
> endian, but that hasn't been tested recently.
It's a PowerBook (ppc32).
The bug is a BUG_ON(spin_trylock(&tree->lock)) in
lookup_extent_mapping() -- I didn't think endiannes
On Mon, 2008-07-21 at 23:32 -0400, David Woodhouse wrote:
> Untested but ObviouslyCorrect™. Now that I can load the module, I hit a
> BUG() immediately -- but I don't think it's caused by this patch. qv.
Current progs-unstable and kernel-unstable. I created a 512MiB file and
ran
Prevents the compiler emitting calls to __udivdi3() from libgcc on some
platforms:
WARNING: "__udivdi3" [/shiny/git/btrfs-kernel-unstable/btrfs.ko] undefined!
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
---
Untested but ObviouslyCorrect™. Now that I can load the mod
/git.kernel.org/?p=linux/kernel/git/dwmw2/btrfs-kernel-unstable.git
http://git.kernel.org/?p=linux/kernel/git/dwmw2/btrfs-progs-unstable.git
http://git.kernel.org/?p=linux/kernel/git/dwmw2/btrfs-kernel.git
http://git.kernel.org/?p=linux/kernel/git/dwmw2/btrfs-progs.git
It should be updated hour
ere I left off
with that.
In the meantime, we have an evil hack which at least ought to work for
now.
--
David WoodhouseOpen Source Technology Centre
[EMAIL PROTECTED] Intel Corporation
--
dwmw2
--
To unsubscribe from this list: send the
On Mon, 2008-07-21 at 00:41 +0530, Balaji Rao wrote:
> Hi,
>
> There's a problem in btrfs_readdir that tries to lock a root node with one
> being held. This happens when NFS calls vfs_readdir function with a nfs
> specific filldir function pointer. This filldir function, called with the
> lock
On Sat, 2008-07-19 at 15:21 +0300, Ahmed Kamal wrote:
> Hi,
> Since btrfs is someday going to be the default FS for Linux, and will
> be on so many single disk PCs and laptops, I was thinking it should be
> a good idea to insert some redundancy in single disk deployments. Of
> course it can help wi
94 matches
Mail list logo
