On Thu, 25 Nov 2010 19:42:53 +0800, Wenyi Liu wrote:
Hi Xie Miao:
I cannot understand the btrfs_decode_error(). why you chose the
three errnos? what about others? eager for Ur replay. Thanks!!
I think liu chose these three errors is because these errors are familiar ones
that are hard to b
On Thu, 25 Nov 2010 11:41:50 +0200 Boaz Harrosh wrote:
> On 11/25/2010 12:47 AM, Andrew Morton wrote:
> > On Tue, 23 Nov 2010 07:34:07 -0500
> > Chris Mason wrote:
> >
> >> For btrfs there's only one bdi per SB, but for most everyone else a disk
> >> with a bunch of partitions is going to have
I'm just not certain whether bcp works across subvolumes or not.
It doesn't seem to work across subvolumes.
--
Tomasz Chmielewski
http://wpkg.org
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info
Hi Xie Miao:
I cannot understand the btrfs_decode_error(). why you chose the
three errnos? what about others? eager for Ur replay. Thanks!!
---
Best Regards,
Liu Wenyi
2010/11/25, Miao Xie :
> From: Liu Bo
>
> This patch provide a new error handle interface for those errors that
> handled
>
2010/11/25, Miao Xie :
> Btrfs has a number of BUG_ON()s, which may lead btrfs to unpleasant panic.
> Meanwhile, they are very ugly and should be handled more propriately.
>
> There are mainly two ways to deal with these BUG_ON()s.
Yes, I agree.
>
> 1. For those errors which can be handled well by
On 25/11/10 10:32, Tomasz Torcz wrote:
> On Thu, Nov 25, 2010 at 04:19:17AM -0600, David Nicol wrote:
>> unresearched question/suggestion:
>>
>> Is there general support for a "fast copy" ioctl in the VFS layer,
>> which would be hooked by file systems that support COW or other forms
>> of deduplic
David Nicol wrote:
unresearched question/suggestion:
Is there general support for a "fast copy" ioctl in the VFS layer,
which would be hooked by file systems that support COW or other forms
of deduplication and can provide copy semantics by manipulating
metadata only?
What would be nice to hav
On Thu, Nov 25, 2010 at 04:19:17AM -0600, David Nicol wrote:
> unresearched question/suggestion:
>
> Is there general support for a "fast copy" ioctl in the VFS layer,
> which would be hooked by file systems that support COW or other forms
> of deduplication and can provide copy semantics by manip
unresearched question/suggestion:
Is there general support for a "fast copy" ioctl in the VFS layer,
which would be hooked by file systems that support COW or other forms
of deduplication and can provide copy semantics by manipulating
metadata only?
--
"It is merely a matter of persistence." --
From: Liu Bo
Add filesystem state and two flags of it to tell if the filesystem is
valid or insane now.
Signed-off-by: Liu Bo
Signed-off-by: Miao Xie
---
fs/btrfs/ctree.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
From: Liu Bo
Since there is a filesystem state, we should deal with it carefully at mount,
umount and remount.
- At mount, the FS state should be checked if there is error on these FS.
If it does have, btrfsck is recommended.
- At umount, the FS state should be saved into disk for consistency
From: Liu Bo
When the filesystem is readonly, commit transaction is forbiddened.
Signed-off-by: Liu Bo
Signed-off-by: Miao Xie
---
fs/btrfs/transaction.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 1fffbc
Btrfs has a number of BUG_ON()s, which may lead btrfs to unpleasant panic.
Meanwhile, they are very ugly and should be handled more propriately.
There are mainly two ways to deal with these BUG_ON()s.
1. For those errors which can be handled well by callers, we just return their
error number to c
From: Liu Bo
This patch provide a new error handle interface for those errors that handled
by current BUG_ONs.
In order to protect btrfs from panic, when it comes to those BUG_ON errors,
the interface forces btrfs readonly and saves the FS state to disk. And the
filesystem can be umounted, alth
On 11/25/2010 12:47 AM, Andrew Morton wrote:
> On Tue, 23 Nov 2010 07:34:07 -0500
> Chris Mason wrote:
>
>> For btrfs there's only one bdi per SB, but for most everyone else a disk
>> with a bunch of partitions is going to have multiple filesystems on the
>> same bdi.
>
> um, please explain why
>> "COW hardlinks" are ref-links (as far as I'm concerned). I said
>> partially implemented, because that's exactly what a snapshot is. I'm
>> just not certain whether bcp works across subvolumes or not. An
>> actual hardlink (i.e., all writes appear in all hardlinks) across any
>> file-system-l
cwillu wrote:
One thing I would like to see is copy-on-write hard-links. The hard-links
that span snapshots should be possible, but they should be copy-on-write,
i.e. as soon as hard-linked file that spans snapshots is written, the
snapshot that wrote it should have it's own forked copy hencefort
17 matches
Mail list logo
