On Sun, Dec 27, 2009 at 3:34 PM, Lex "x-demon" Rivera
wrote:
> Btrfs fails randomly, after this error in dmesg i can't exec any apps,
> but can read/write to disc. Log attached, it's always the same, except
> process that caused this.
>
> t fs/btrfs/ordered-data.c:672!
> invalid opcode: [#1]
Thank you for your mail.
I intended to create a swap utility including root subvolume.
That was the goal. Swapping root subvolume is not implemented
yet...
For now, as you say, in some cases this utility does simple
mv commands, but in some cases, it has some advantages.
We can swap subvolumes r
On Sun, 27 Dec 2009 at 17:33, ty...@mit.edu wrote:
> Yes, but given many of the file systems have almost *exactly* the same
"Almost" indeed - but curiously enough some filesystem are *not* the same,
although they should. Again: we have 8GB RAM, I'm copying ~3GB of data, so
why _are_ there differ
Thank you, I don't think of a devices scan.
After all, I wonder why. Return codes must be
coherent so that we can know good from no-good
by them. In this spec, it's very hard to make
shell scripts with btrfsctl. If there isn't good
reason, we need to fix it, I think.
(2009/12/25 18:25), Goffredo
On Sun, Dec 27, 2009 at 01:55:26PM -0800, Christian Kujau wrote:
> On Sun, 27 Dec 2009 at 14:50, jim owens wrote:
> > And I don't even care about comparing 2 filesystems, I only care about
> > timing 2 versions of code in the single filesystem I am working on,
> > and forgetting about hardware cach
On Sun, 27 Dec 2009 at 14:50, jim owens wrote:
> And I don't even care about comparing 2 filesystems, I only care about
> timing 2 versions of code in the single filesystem I am working on,
> and forgetting about hardware cache effects has screwed me there.
Not me, I'm comparing filesystems - an
On Thursday 24 December 2009, TARUISI Hiroaki wrote:
> New utility(btrfsrevert) added to swap subvolumes.
>
> With this utility, a subvolume (Source Subvolume) takes place of
> another subvolume (Target Subvolume), and target subvolume goes
> under hidden directory(".old_trees") in filesystem root
Christian Kujau wrote:
> On 26.12.09 08:00, jim owens wrote:
>>> I was using "sync" to make sure that the data "should" be on the disks
>> Good, but not good enough for many tests... info sync
> [...]
>>On Linux, sync is only guaranteed to schedule the dirty blocks
>> for
>>w
