2010/4/26 C Anthony Risinger :
> hello,
>
> i maintain an unofficial initrd hook in Arch Linux that allows BTRFS
> to be used as the root device. i am trying to update the hook to use
> the more extensive "btrfs" command, adding support for users to change
> their default subvolume from within the
2010/4/26 C Anthony Risinger :
>> need super root? in my ubuntu10.04 with latest btrfs-progs:
>>
>> $ ./btrfs subvolume list /media/sda3-100g/
>> ERROR: can't perform the search
>> $ sudo ./btrfs subvolume list /media/sda3-100g/
>> ID 258 top level 5 path misc/snap/snap-4-26
>
> ah sorry, i forgot
Hi all,
I tried to reproduce the bug reported by Tomas Thiemel
(http://www.spinics.net/lists/linux-btrfs/msg04818.html) with loop
device, and caught a bug report.
kernel: v2.6.34-rc5-279-g1600f9d
btrfs_progs: v0.19-16-g075587c
cd /tmp
mkdir mnt0
mkdir mnt1
dd if=/dev/zero of=./disk0 bs=1M count=
> I have sent a set of patches that address bugs like this.
>
I applied the V2 patchset to kernel-v2.6.32 (actually, I applied them
to btrfs-unstalbe, took a kernel-v2.6.32 and replaced its btrfs with
the patched one in btrfs-unstable), and did the test, then got:
$ sudo btrfs device del /dev/loo
On Fri, Jan 16, 2009 at 10:31 PM, Chris Mason wrote:
> On Fri, 2009-01-16 at 15:25 +0800, Qinghuang Feng wrote:
>> merge list_for_each and list_entry to list_for_each_entry.
>>
>
> Thanks, I've queued this up.
>
Good, but
Now I have made a new patch for cleanupping all the similar codes in bt
31 int btrfs_defrag_leaves(struct btrfs_trans_handle *trans,
32 struct btrfs_root *root, int cache_only)
33 {
...
45 if (cache_only) //check once
46 goto out;
79 root->defrag_max.objectid = 0; //needless? The
following co
2009/12/12 Goffredo Baroncelli :
> Hi all,
>
> I found the help of the btrfctl command very poor. I rewrite some help
> messages and correct (or added when needed) the check of the number of
> parameter.
>
> Please apply.
>
>
> * Improve/correct the check of the arguments number
> * Revise the comm
No, many pointers in btrfs function arguments are not pointing to an
absolute address, but relative to the start address of extent.
Take following function as example, argument inode_item is an offset
value to the beginning of leaf. So we can't reach its member with
&inode_item->xxx
> static inl
2009/12/18 Zhaolei :
> sniper wrote:
>> No, many pointers in btrfs function arguments are not pointing to an
>> absolute address, but relative to the start address of extent.
>> Take following function as example, argument inode_item is an offset
>> value to the beg