Am Donnerstag, 26. April 2012 schrieb Bart Noordervliet:
> On Thu, Apr 26, 2012 at 11:06, Thomas Rohwer wrote:
> >> As for the two filesystems shown in btrfs fi show... I have no clue
> >> what that is about. Did you maybe make a mistake to create a btrfs
> >> filesystem on the whole disk at first
Hubert Kario posted on Sat, 28 Apr 2012 18:42:52 +0200 as excerpted:
> On Thursday 26 of April 2012 20:54:47 Duncan wrote:
>> Helmut Hullen posted on Thu, 26 Apr 2012 13:11:00 +0200 as excerpted:
>> > Hallo, Bart,
>> >>
>> >> Well I think there is a btrfs superblock still present from the
>> >> f
On Sunday 01 of April 2012 11:42:23 Jérôme Poulin wrote:
> On Sun, Apr 1, 2012 at 11:27 AM, Norbert Scheibner wrote:
> > Some users tested this patch successfully for week,s or months in 2 or 3
> > kernel versions since then, true?
> If this feature must be implented in VFS in another patch, why n
On Thursday 26 of April 2012 20:54:47 Duncan wrote:
> Helmut Hullen posted on Thu, 26 Apr 2012 13:11:00 +0200 as excerpted:
> > Hallo, Bart,
> >>
> >> Well I think there is a btrfs superblock still present from the
> >> full-disk filesystem. Due to the offset of the first partition from the
> >> s
On 25 Apr 2012, at 13:42, Jan Schmidt wrote:
> btrfs_map_block sets mirror_num, so that the repair code knows eventually
> which device gave us the read error. For RAID10, mirror_num must be 1 or 2.
> Before this fix mirror_num was incorrectly related to our stripe index.
>
> Signed-off-by: Jan
Hi everyone,
The for-linus branch of the btrfs git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
Has our collection of bug fixes. I missed the last rc because I thought
our patches were making NFS crash during my xfs test runs. Turns out it
was an NFS clie
