On Fri, Apr 15, 2016 at 12:51 AM, Satoru Takeuchi
wrote:
> sample output:
>
> # ./sub-list-with-ro.rb /
> ID gen top level pathro
> -- --- - --
> 257 48672 5 root
On 2016/04/15 10:55, Chris Murphy wrote:
Hi,
I'm realizing instead of doing 'btrfs subvolume -t' and then 'btrfs
subvolume -tr' and comparing, it would be better if -t just had a
column for whether a subvolume is ro. And maybe it's useful to know if
a subvolume is a snapshot or not (?). I'm not
Hi,
I'm realizing instead of doing 'btrfs subvolume -t' and then 'btrfs
subvolume -tr' and comparing, it would be better if -t just had a
column for whether a subvolume is ro. And maybe it's useful to know if
a subvolume is a snapshot or not (?). I'm not super picky about the
last one. But being a
Filipe Manana wrote on 2016/04/14 10:21 +0100:
On Thu, Apr 14, 2016 at 6:34 AM, Qu Wenruo wrote:
Ping?
Cc: Chris and David
It seems that this fix is missing in 4.6 merge window.
Or did I miss something?
4.5-rc7: https://lkml.org/lkml/2016/3/4/695
Strangely, not in integration-4.6.
Thi
Mark Fasheh wrote on 2016/04/14 14:42 -0700:
Hi Qu,
On Thu, Apr 14, 2016 at 01:38:40PM +0800, Qu Wenruo wrote:
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounti
Mark Fasheh wrote on 2016/04/14 14:42 -0700:
Hi Qu,
On Thu, Apr 14, 2016 at 01:38:40PM +0800, Qu Wenruo wrote:
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_extents() there must be a commit root switch.
Normally this is OK, as btrfs_qgroup_accounti
Swâmi Petaramesh posted on Thu, 14 Apr 2016 18:56:29 +0200 as excerpted:
> It seems that i have a "btrfs check" process that’s stuck in an infinite
> recursive loop…
>
> How could I end this without breaking my filesystem ?
...
> root@PartedMagic:~# btrfs check --repair /dev/VGZ/LINUX
> enablin
On Tue, Apr 12, 2016 at 10:15:50PM +0800, Anand Jain wrote:
> Thanks for various comments, tests and feedback.
Hmm... Yet another lockdep warning, appeared when I removed target drive
during of replacing:
[ 5375.718844]
[ 5375.718845] ==
[ 5375
is_seen_fsid() uses simple hash to check if FS was seen before at
walking on FS list in 'filesystem show' command: hash key is first byte
of the UUID. This function doesn't check full UUID then, so, if there
are two FS with same first byte in UUIDs exist, only one will be shown:
root@test:~# btrfs
Test that an invalid parent qgroup does not cause snapshot create to
force the FS readonly.
In btrfs, create_pending_snapshot() will go readonly on _a
Hi Qu,
On Thu, Apr 14, 2016 at 01:38:40PM +0800, Qu Wenruo wrote:
> Current btrfs qgroup design implies a requirement that after calling
> btrfs_qgroup_account_extents() there must be a commit root switch.
>
> Normally this is OK, as btrfs_qgroup_accounting_extents() is only called
> inside btrfs
Dear btrfs community,
I have the following setup:
# btrfs fi show /home
Label: none uuid: 865f8cf9-27be-41a0-85a4-6cb4d1658ce3
Total devices 3 FS bytes used 55.68GiB
devid1 size 52.91GiB used 0.00B path /dev/sdd2
devid2 size 232.89GiB used 59.03GiB path /dev/sda
On Tue, Apr 12, 2016 at 10:15:50PM +0800, Anand Jain wrote:
> Thanks for various comments, tests and feedback.
Tested-By: Yauhen Kharuzhy ,
for all patches in the series.
--
Yauhen Kharuzhy
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to maj
On Thu, Apr 14, 2016 at 06:51:58PM +0800, Anand Jain wrote:
> From: Anand Jain
>
> This patch provides helper functions to force a device to offline
> or failed, and we need this device states for the following reasons,
> 1) a. it can be reported that device has failed when it does
>b. close
Hi folks,
It seems that i have a "btrfs check" process that’s stuck in an infinite
recursive loop…
How could I end this without breaking my filesystem ?
Help much needed & appreciated…
TIA.
Kind regards.
root@PartedMagic:~# btrfs check --repair /dev/VGZ/LINUX
enabling repair mode
Checking fi
Hi Chandan,
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.6-rc3 next-20160414]
[cannot apply to btrfs/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Chandan
Hi Chandan,
[auto build test WARNING on tip/perf/core]
[also build test WARNING on v4.6-rc3 next-20160414]
[cannot apply to btrfs/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Chandan
In order to handle multiple extent buffers per page, first we need to create a
way to handle all the extent buffers that are attached to a page.
This patch creates a new data structure 'struct extent_buffer_head', and moves
fields that are common to all extent buffers from 'struct extent_buffer' t
For the subpage-blocksize scenario, this patch adds the ability to write
a single extent buffer to the disk.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/disk-io.c | 32 +++---
fs/btrfs/extent_io.c | 277 +--
2 files changed, 242 insertions(+),
The function implementing the dedupe ioctl
i.e. btrfs_ioctl_file_extent_same(), returns with an error in
subpage-blocksize scenario. This was done due to the fact that Btrfs did
not have code to deal with block size < page size. This commit removes
this restriction since we now support "block size
The file extent relocation code currently assumes blocksize to be same
as PAGE_SIZE. This commit adds code to support subpage blocksize
scenario.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/relocation.c | 73 +--
1 file changed, 48 insertions(+),
For the subpage-blocksize scenario, a page can contain multiple
blocks. In such cases, this patch handles writing data to files.
Also, When setting EXTENT_DELALLOC, we no longer set EXTENT_UPTODATE bit on
the extent_io_tree since uptodate status is being tracked by the bitmap
pointed to by page->p
find_delalloc_range indirectly depends on EXTENT_UPTODDATE to make sure that
the delalloc range returned intersects with the file range mapped by the
page. Since we now track "uptodate" state in a per-page
bitmap (i.e. in btrfs_page_private->bstate), this commit makes an explicit
check to make sure
After cloning the required extents, we truncate all the pages that map
the file range being cloned. In subpage-blocksize scenario, we could
have dirty blocks before and/or after the clone range in the
leading/trailing pages. Truncating these pages would lead to data
loss. Hence this commit forces s
This commit gets file defragmentation code to work in subpage-blocksize
scenario. It does this by keeping track of page offsets that mark block
boundaries and passing them as arguments to the functions that implement
the defragmentation logic.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/ioctl.c
In case of subpage-blocksize, the file blocks to be punched may map only
part of a page. For file blocks inside such pages, we need to check for
the presence of BLK_STATE_UPTODATE flag.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/file.c | 66 +
In subpage-blocksize scenario, extent allocations for only some of the
dirty blocks of a page can succeed, while allocation for rest of the
blocks can fail. This patch allows I/O against such pages to be
submitted.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/extent_io.c | 27 ++-
For the subpage-blocksize scenario, a page can contain multiple
blocks. In such cases, this patch handles reading data from files.
To track the status of individual blocks of a page, this patch makes use
of a bitmap pointed to by the newly introduced per-page 'struct
btrfs_page_private'.
The per-
extent_clear_unlock_delalloc() can unlock a page more than once as shown
below (assume 4k as the block size and 64k as the page size).
cow_file_range
create 4k ordered extent corresponding to page offsets 0 - 4095
extent_clear_unlock_delalloc corresponding to page offsets 0 - 4095
unlock p
Btrfs assumes block size to be the same as the machine's page
size. This would mean that a Btrfs instance created on a 4k page size
machine (e.g. x86) will not be mountable on machines with larger page
sizes (e.g. PPC64/AARCH64). This patchset aims to resolve this
incompatibility.
This patchset co
In subpage-blocksize scenario a page can have more than one block. So in
addition to PagePrivate2 flag, we would have to track the I/O status of
each block of a page to reliably mark the ordered extent as complete.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/extent_io.c| 19 +--
fs/btrfs/e
In the case of subpage-blocksize, this patch makes it possible to read
only a single metadata block from the disk instead of all the metadata
blocks that map into a page.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/disk-io.c | 52 +
fs/btrfs/disk-io.h | 3 ++
fs/btrfs
In __btrfs_lookup_bio_sums() we set the file offset value at the
beginning of every iteration of the while loop. This is incorrect since
the blocks mapped by the current bvec->bv_page might not yet have been
completely processed.
This commit fixes the issue by setting the file offset value when we
This patch allows mounting filesystems with sectorsize smaller than the
PAGE_SIZE.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/disk-io.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 708b8cb..1db0063 100644
--- a/fs/
The patch "Btrfs: subpage-blocksize: Prevent writes to an extent buffer
when PG_writeback flag is set" requires btrfs_try_tree_write_lock() to
be a true try lock w.r.t to both spinning and blocking locks. During
2015's Vault Conference Btrfs meetup, Chris Mason had suggested that he
will write up a
In non-subpage-blocksize scenario, BTRFS_HEADER_FLAG_WRITTEN flag
prevents Btrfs code from writing into an extent buffer whose pages are
under writeback. This facility isn't sufficient for achieving the same
in subpage-blocksize scenario, since we have more than one extent buffer
mapped to a page.
On 04/14/2016 05:21 PM, Filipe Manana wrote:
On Thu, Apr 14, 2016 at 2:30 AM, Qu Wenruo wrote:
Filipe Manana wrote on 2016/04/13 17:23 +0100:
On Tue, Apr 12, 2016 at 8:35 AM, Qu Wenruo
wrote:
Current btrfs qgroup design implies a requirement that after calling
btrfs_qgroup_account_exte
Hello all,
I accidentally sent out patches from the incorrect branch. Please ignore this
patchset.
--
chandan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-
From: Anand Jain
This patch provides helper functions to force a device to offline
or failed, and we need this device states for the following reasons,
1) a. it can be reported that device has failed when it does
b. close the device when it goes offline so that blocklayer can
cleanup
2)
Yauhen reported in the ML that s_bdev is null at mount, and
s_bdev gets updated to some device when missing device is
replaced, as because bdev is null for missing device, things
gets matched up. Fix this by checking if s_bdev is set. I
didn't want to completely remove updating s_bdev because
the f
Hi Chandan,
[auto build test WARNING on tip/perf/core]
[also build test WARNING on v4.6-rc3 next-20160414]
[cannot apply to btrfs/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Chandan
On 04/14/2016 05:22 PM, Yauhen Kharuzhy wrote:
On Thu, Apr 14, 2016 at 04:45:11PM +0800, Anand Jain wrote:
Thanks for the report ! more below..
You may use simpler devmgt tool, https://github.com/asj/devmgt
Thanks, will try.
You are failing the replace-target, presumably when the
On 04/14/2016 05:10 PM, Yauhen Kharuzhy wrote:
On Thu, Apr 14, 2016 at 02:59:23PM +0800, Anand Jain wrote:
Hi Yauhen
On 04/14/2016 09:15 AM, Yauhen Kharuzhy wrote:
fs_info->sb->s_bdev field isn't set to any value at mount time
There were patch to do set it at the vfs layer, or somethin
Hi Chandan,
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.6-rc3 next-20160414]
[cannot apply to btrfs/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Chandan
On Thu, Apr 14, 2016 at 04:45:11PM +0800, Anand Jain wrote:
>
>
>
> Thanks for the report ! more below..
>
>
> You may use simpler devmgt tool, https://github.com/asj/devmgt
Thanks, will try.
>
> You are failing the replace-target, presumably when the replace is
> still running, however
On Thu, Apr 14, 2016 at 6:34 AM, Qu Wenruo wrote:
> Ping?
>
> Cc: Chris and David
>
> It seems that this fix is missing in 4.6 merge window.
> Or did I miss something?
4.5-rc7: https://lkml.org/lkml/2016/3/4/695
>
> Thanks,
> Qu
>
>
> Filipe Manana wrote on 2016/03/03 09:10 +:
>>
>> On Thu,
On Thu, Apr 14, 2016 at 2:30 AM, Qu Wenruo wrote:
>
>
> Filipe Manana wrote on 2016/04/13 17:23 +0100:
>>
>> On Tue, Apr 12, 2016 at 8:35 AM, Qu Wenruo
>> wrote:
>>>
>>> Current btrfs qgroup design implies a requirement that after calling
>>> btrfs_qgroup_account_extents() there must be a commit
On Thu, Apr 14, 2016 at 02:59:23PM +0800, Anand Jain wrote:
>
>
> Hi Yauhen
>
> On 04/14/2016 09:15 AM, Yauhen Kharuzhy wrote:
> >fs_info->sb->s_bdev field isn't set to any value at mount time
>
> There were patch to do set it at the vfs layer, or something like that.
>
> >but is set
> >after
Thanks for the report ! more below..
On 04/14/2016 05:21 AM, Yauhen Kharuzhy wrote:
On Tue, Apr 12, 2016 at 10:15:50PM +0800, Anand Jain wrote:
Thanks for various comments, tests and feedback.
Hmm... I broke it :)
I get kernel oops after few cycles of drive removing-insertion-replacing.
In case of subpage-blocksize, the file blocks to be punched may map only
part of a page. For file blocks inside such pages, we need to check for
the presence of BLK_STATE_UPTODATE flag.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/file.c | 66 +
In __btrfs_lookup_bio_sums() we set the file offset value at the
beginning of every iteration of the while loop. This is incorrect since
the blocks mapped by the current bvec->bv_page might not yet have been
completely processed.
This commit fixes the issue by setting the file offset value when we
The patch "Btrfs: subpage-blocksize: Prevent writes to an extent buffer
when PG_writeback flag is set" requires btrfs_try_tree_write_lock() to
be a true try lock w.r.t to both spinning and blocking locks. During
2015's Vault Conference Btrfs meetup, Chris Mason had suggested that he
will write up a
This commit gets file defragmentation code to work in subpage-blocksize
scenario. It does this by keeping track of page offsets that mark block
boundaries and passing them as arguments to the functions that implement
the defragmentation logic.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/ioctl.c
In the case of subpage-blocksize, this patch makes it possible to read
only a single metadata block from the disk instead of all the metadata
blocks that map into a page.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/disk-io.c | 52 +
fs/btrfs/disk-io.h | 3 ++
fs/btrfs
For the subpage-blocksize scenario, this patch adds the ability to write
a single extent buffer to the disk.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/disk-io.c | 32 +++---
fs/btrfs/extent_io.c | 277 +--
2 files changed, 242 insertions(+),
extent_clear_unlock_delalloc() can unlock a page more than once as shown
below (assume 4k as the block size and 64k as the page size).
cow_file_range
create 4k ordered extent corresponding to page offsets 0 - 4095
extent_clear_unlock_delalloc corresponding to page offsets 0 - 4095
unlock p
The function implementing the dedupe ioctl
i.e. btrfs_ioctl_file_extent_same(), returns with an error in
subpage-blocksize scenario. This was done due to the fact that Btrfs did
not have code to deal with block size < page size. This commit removes
this restriction since we now support "block size
In subpage-blocksize scenario, extent allocations for only some of the
dirty blocks of a page can succeed, while allocation for rest of the
blocks can fail. This patch allows I/O against such pages to be
submitted.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/extent_io.c | 27 ++-
After cloning the required extents, we truncate all the pages that map
the file range being cloned. In subpage-blocksize scenario, we could
have dirty blocks before and/or after the clone range in the
leading/trailing pages. Truncating these pages would lead to data
loss. Hence this commit forces s
This patch allows mounting filesystems with sectorsize smaller than the
PAGE_SIZE.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/disk-io.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 708b8cb..1db0063 100644
--- a/fs/
The file extent relocation code currently assumes blocksize to be same
as PAGE_CACHE_SIZE. This commit adds code to support subpage blocksize
scenario.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/ioctl.c | 10 +++
fs/btrfs/relocation.c | 73 +
In non-subpage-blocksize scenario, BTRFS_HEADER_FLAG_WRITTEN flag
prevents Btrfs code from writing into an extent buffer whose pages are
under writeback. This facility isn't sufficient for achieving the same
in subpage-blocksize scenario, since we have more than one extent buffer
mapped to a page.
find_delalloc_range indirectly depends on EXTENT_UPTODDATE to make sure that
the delalloc range returned intersects with the file range mapped by the
page. Since we now track "uptodate" state in a per-page
bitmap (i.e. in btrfs_page_private->bstate), this commit makes an explicit
check to make sure
For the subpage-blocksize scenario, a page can contain multiple
blocks. In such cases, this patch handles writing data to files.
Also, When setting EXTENT_DELALLOC, we no longer set EXTENT_UPTODATE bit on
the extent_io_tree since uptodate status is being tracked by the bitmap
pointed to by page->p
In order to handle multiple extent buffers per page, first we need to create a
way to handle all the extent buffers that are attached to a page.
This patch creates a new data structure 'struct extent_buffer_head', and moves
fields that are common to all extent buffers from 'struct extent_buffer' t
For the subpage-blocksize scenario, a page can contain multiple
blocks. In such cases, this patch handles reading data from files.
To track the status of individual blocks of a page, this patch makes use
of a bitmap pointed to by the newly introduced per-page 'struct
btrfs_page_private'.
The per-
In subpage-blocksize scenario a page can have more than one block. So in
addition to PagePrivate2 flag, we would have to track the I/O status of
each block of a page to reliably mark the ordered extent as complete.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/extent_io.c| 19 +--
fs/btrfs/e
Btrfs assumes block size to be the same as the machine's page
size. This would mean that a Btrfs instance created on a 4k page size
machine (e.g. x86) will not be mountable on machines with larger page
sizes (e.g. PPC64/AARCH64). This patchset aims to resolve this
incompatibility.
This patchset co
Hi Yauhen
On 04/14/2016 09:15 AM, Yauhen Kharuzhy wrote:
fs_info->sb->s_bdev field isn't set to any value at mount time
There were patch to do set it at the vfs layer, or something like that.
but is set
after device replacing or at device closing.
Actually we are updating s_bdev/latest
69 matches
Mail list logo
