On Sat, Jan 8, 2011 at 5:25 AM, Carl Cook wrote:
>
> In addition to the questions below, if anyone has a chance could you advise
> on why my destination drive has more data than the source after this command:
> # rsync --hard-links --delete --inplace --archive --numeric-ids /media/disk/*
> /hom
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've got the same problem. That is, I have a 2.6.35 btrfs volume that
segfaults and causes a kernel oops upon attempts to mount it. There is
some data on there that was not covered by the daily backup. Though it
is not the end of the world, I'd like t
Olaf van der Spek wrote:
On Fri, Jan 7, 2011 at 8:29 PM, Thomas Bellman wrote:
What is the visibility of the changes for other processes supposed
to be in the meantime? I.e., if things happen in this order:
Should be atomic too, at close time.
1. Process A does fda = open("foo.txt", O_TRU
On Fri, 7 Jan 2011, Aneesh Kumar K. V wrote:
> On Thu, 6 Jan 2011 22:45:21 +0100 (CET), Jesper Juhl
> wrote:
> >
> > It seems to me that we leak the memory allocated to 'value' in
> > btrfs_get_acl() if the call to posix_acl_from_xattr() fails.
> > Here's a patch that attempts to correct that
On Sat, Jan 08, 2011 at 05:25:19AM -0800, Carl Cook wrote:
> In addition to the questions below, if anyone has a chance could you
> advise on why my destination drive has more data than the source after
> this command:
> # rsync --hard-links --delete --inplace --archive --numeric-ids /media/disk/*
On Fri, Jan 7, 2011 at 8:29 PM, Chris Mason wrote:
> The exact amount of tracking is going to vary. The reason why is that
> actually doing the truncate is an O(size of the file) operation and so
> you can't just flip a switch when the write or the close comes in. You
> have to run through all t
On Fri, Jan 7, 2011 at 8:29 PM, Thomas Bellman wrote:
> What is the visibility of the changes for other processes supposed
> to be in the meantime? I.e., if things happen in this order:
Should be atomic too, at close time.
> 1. Process A does fda = open("foo.txt", O_TRUNC|O_ATOMIC)
> 2. Process
In addition to the questions below, if anyone has a chance could you advise on
why my destination drive has more data than the source after this command:
# rsync --hard-links --delete --inplace --archive --numeric-ids /media/disk/*
/home
sending incremental file list
sent 658660 bytes received
On Sat, Jan 8, 2011 at 5:29 AM, cwillu wrote:
> On Fri, Jan 7, 2011 at 3:15 PM, Andrew Schretter
> wrote:
>> I have a 10TB btrfs filesystem over iSCSI that is currently unmountable. I'm
>> currently running Fedora 13 with a recent Fedora 14 kernel
>> (2.6.35.9-64.fc14.i686.PAE)
>> and the syst
I happened to pass swap partition as root partition in cmdline,
then kernel panic and tell me about "Cannot open root device".
It is not correct, in fact it is a fs type mismatch instead of 'no device'.
Eventually I found btrfs mounting failed with -EIO, it should be -EINVAL.
The logic in init/do_
Hello again,
(this is a status update)
from what I begin to understand, the real problem is not the transid,
which is a kind of warning, but the failed assertion on "tree_root",
meaning that the read_tree_block call at disk-io.nc:736 fails.
The GDB backtrace is the following :
Reading symbols f
11 matches
Mail list logo
