On 01/31/2014 02:24 AM, Russell Coker wrote:
The attached dmesg log shows the results of trying to cat a file on a BTRFS
filesystem when running the latest Debian/Unstable kernel (upstream 3.12.8
with some Debian patches that probably aren't relevant to BTRFS).
I've rebooted the Thinkpad in
On Fri 31 Jan 2014 09:07:15 AM EST, Josef Bacik wrote:
On 01/31/2014 02:24 AM, Russell Coker wrote:
The attached dmesg log shows the results of trying to cat a file on a
BTRFS
filesystem when running the latest Debian/Unstable kernel (upstream
3.12.8
with some Debian patches that probably
Hello Josef,
在 2014-1-31，上午12:23，Josef Bacik jba...@fb.com 写道：
On 01/30/2014 11:20 AM, Wang Shilong wrote:
Hello Josef,
On 01/30/2014 04:42 AM, Wang Shilong wrote:
Hi Josef,
On 01/29/2014 10:32 AM, Wang Shilong wrote:
From: Wang Shilong wangsl.f...@cn.fujitsu.com
I sent a
From: Wang Shilong wangsl.f...@cn.fujitsu.com
Since we have introduced btrfs_previous_extent_item() to search previous
extent item, just switch into it.
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
fs/btrfs/backref.c | 34 +++---
1 file changed, 3
From: Wang Shilong wangsl.f...@cn.fujitsu.com
find_all_leafs() dosen't need add all roots actually, add roots only
if we need, this can avoid unnecessary ulist dance.
Signed-off-by: Wang Shilong wangsl.f...@cn.fujitsu.com
---
fs/btrfs/backref.c | 14 +++---
1 file changed, 3
On Thu, Jan 30, 2014 at 04:23:56PM +0100, Gerhard Heift wrote:
This patch series first rewrites tree_search to copy found items directly to
userspace and then adds a new ioctl TREE_SEARCH_V2 with which we could store
them in a varying buffer. Now even items larger than 3992 bytes or a large
On Fri, Jan 31, 2014 at 09:11:29AM -0500, Chris Mason wrote:
On Fri 31 Jan 2014 09:07:15 AM EST, Josef Bacik wrote:
On 01/31/2014 02:24 AM, Russell Coker wrote:
The attached dmesg log shows the results of trying to cat a file on a
BTRFS
filesystem when running the latest Debian/Unstable
I do not know if people her are aware of it, but just in case I thought
it is worth mentioning that currently it is not possible to boot with
Syslinux bootloader, if the boot partition is on BTRFS.
Perhaps it's worth adding to the wiki.
--
To unsubscribe from this list: send the line
On Fri, Jan 31, 2014 at 08:46:10PM +0100, KC wrote:
I do not know if people her are aware of it, but just in case I
thought it is worth mentioning that currently it is not possible to
boot with Syslinux bootloader, if the boot partition is on BTRFS.
Perhaps it's worth adding to the wiki.
Use extlinux, variant of syslinux.
Use extlinux, variant of syslinux.
Chris Murphy
Sorry KC:
All my VM's are on syslinux (actually extlinux) and btrfs:
Device Boot Start End Blocks Id System
/dev/vda1 *2048 7938047 3968000 83 Linux
/dev/vda2 7938048 8388607 225280 82 Linux swap / Solaris
root@VM ~ # ll /boot
On 01/31/2014 11:37 AM, Wang Shilong wrote:
Hello Josef,
在 2014-1-31，上午12:23，Josef Bacik jba...@fb.com 写道：
On 01/30/2014 11:20 AM, Wang Shilong wrote:
Hello Josef,
On 01/30/2014 04:42 AM, Wang Shilong wrote:
Hi Josef,
On 01/29/2014 10:32 AM, Wang Shilong wrote:
From: Wang Shilong
This fixes a case that the commit titled:
Btrfs: fix infinite path build loops in incremental send
didn't cover. If the parent-child relationship between 2 directories
is inverted, both get renamed, and the former parent has a file that
got renamed too (but remains a child of that directory),
The commit titled Btrfs: fix infinite path build loops in incremental send
didn't cover a particular case where the parent-child relationship inversion
of directories doesn't imply a rename of the new parent directory. This was
due to a simple logic mistake, a logical and instead of a logical or.
This change adds some new tests for btrfs' incremental send feature.
These are all related with inverting the parent-child relationship
of directories, and cover the cases:
* when the new parent didn't get renamed (just moved)
* when a child file of the former parent gets renamed too
These new
16 matches
Mail list logo
