In subpagesize-blocksize a page can map multiple extent buffers and hence
using (page index, seq) as the search key is incorrect. For example, searching
through tree modification log tree can return an entry associated with the
first extent buffer mapped by the page (if such an entry exists), when
While at it, this commit changes btrfs_truncate_page() to truncate sectorsized
blocks instead of pages. Hence the function has been renamed to
btrfs_truncate_block().
Signed-off-by: Chandan Rajendra
---
fs/btrfs/ctree.h | 2 +-
fs/btrfs/file.c | 47 +
Currently, the code reserves/releases extents in multiples of PAGE_CACHE_SIZE
units. Fix this by doing reservation/releases in block size units.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/file.c | 44 +++-
1 file changed, 31 insertions(+), 13 deletions(-
In subpagesize-blocksize scenario, map_length can be less than the length of a
bio vector. Such a condition may cause btrfs_submit_direct_hook() to submit a
zero length bio. Fix this by comparing map_length against block size rather
than with bv_len.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/
Checksums are applicable to sectorsize units. The current code uses
bio->bv_len units to compute and look up checksums. This works on machines
where sectorsize == PAGE_SIZE. This patch makes the checksum computation and
look up code to work with sectorsize units.
Reviewed-by: Liu Bo
Signed-off-by
The direct I/O read's endio and corresponding repair functions work on
page sized blocks. This commit adds the ability for direct I/O read to work on
subpagesized blocks.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/inode.c | 96 ++--
1 file ch
Hello all,
The patches posted along with this cover letter are cleanups made
during the developement of subpagesize-blocksize patchset. I believe
that they can be integrated with the mainline kernel. Hence I have
posted them separately from the subpagesize-blocksize patchset.
I have testsed the p
cow_file_range_inline() limits the size of an inline extent to
PAGE_CACHE_SIZE. This breaks in subpagesize-blocksize scenarios. Fix this by
comparing against root->sectorsize.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
In subpagesize-blocksize scenario, if i_size occurs in a block which is not
the last block in the page, then the space to be reserved should be calculated
appropriately.
Reviewed-by: Liu Bo
Signed-off-by: Chandan Rajendra
---
fs/btrfs/inode.c | 36 +++-
1 file ch
In subpagesize-blocksize scenario it is not sufficient to search using the
first byte of the page to make sure that there are no ordered extents
present across the page. Fix this.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/extent_io.c | 3 ++-
fs/btrfs/inode.c | 25 ++-
When extending a file by either "truncate up" or by writing beyond i_size, the
page which had i_size needs to be marked "read only" so that future writes to
the page via mmap interface causes btrfs_page_mkwrite() to be invoked. If not,
a write performed after extending the file via the mmap interfa
btrfs_getattr() returns PAGE_CACHE_SIZE as the block size. Since
generic_fillattr() already does the right thing (by obtaining block size
from inode->i_blkbits), just remove the statement from btrfs_getattr.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/inode.c | 1 -
1 file changed, 1 deletion(-
On Fri, Aug 07, 2015 at 07:16:04AM +0200, Hendrik Friedel wrote:
> Hello Quo,
>
> thanks for your reply.
>
> >> But then:
> >>root@homeserver:/mnt/__Complete_Disk# btrfs fi df /mnt/__Complete_Disk/
> >>Data, RAID5: total=3.83TiB, used=3.78TiB
> >>System, RAID5: total=32.00MiB, used=576.00KiB
> >>
Mark's patch titled
"[PATCH 3/5] btrfs: fix clone / extent-same deadlocks" [1]
from his "btrfs: dedupe fixes, features" series is missing from the
integration-4.2 tree and 4.2-rc5, where it still applies cleanly (as of 5 mins
ago).
Any particular reason why this was silently dropped?
-h
[
The file layout is
[extent 1]...[extent n][4k extent][HOLE][extent x]
extent 1~n and 4k extent can be merged during defrag, and the whole
defrag bytes is larger than our defrag thresh(256k), 4k extent as a
tail is left unmerged since we check if its next extent can be merged
(the next one is a ho
Hi, I was wondering.
What exactly is contained in btrfs metadata?
I've read about some users setting up their btrfs volumes as
data=single, but metadata=raid1
Is there any actual benefit to that? I mean, if you keep your data as
single, but have multiple copies of metadata, does that still allow
Writing a xfstests case for this, will come soon.
Thanks,
-liubo
On Fri, Aug 07, 2015 at 04:48:41PM +0800, Liu Bo wrote:
> The file layout is
>
> [extent 1]...[extent n][4k extent][HOLE][extent x]
>
> extent 1~n and 4k extent can be merged during defrag, and the whole
> defrag bytes is larger
On Fri, 7 Aug 2015 06:49:58 PM Robert Krig wrote:
> What exactly is contained in btrfs metadata?
Much the same as in metadata for every other filesystem.
> I've read about some users setting up their btrfs volumes as
> data=single, but metadata=raid1
>
> Is there any actual benefit to that? I me
On 7 August 2015 at 00:17, Peter Foley wrote:
> Hi,
>
> I have an btrfs volume that spans multiple disks (no raid, just
> single), and earlier this morning I hit some hardware problems with
> one of the disks.
> I tried btrfs dev del /dev/sda1 /, but btrfs was unable to migrate the
> 1gb that appe
On Friday 07 August 2015 19:18:02 Russell Coker wrote:
> On Fri, 7 Aug 2015 06:49:58 PM Robert Krig wrote:
> > What exactly is contained in btrfs metadata?
>
> Much the same as in metadata for every other filesystem.
>
> > I've read about some users setting up their btrfs volumes as
> > data=sing
On Wed, Jul 22, 2015 at 11:14 AM, Anand Jain wrote:
> From: Anand Jain
>
> Controlled EIO from the device is achieved using the dm device.
> Helper functions are at common/dmerror.
>
> Broadly steps will include calling _init_dmerror().
> _init_dmerror() will use SCRATCH_DEV to create dm linear d
Robert Krig posted on Fri, 07 Aug 2015 10:49:58 +0200 as excerpted:
> Hi, I was wondering.
>
> What exactly is contained in btrfs metadata?
>
> I've read about some users setting up their btrfs volumes as
> data=single, but metadata=raid1
>
> Is there any actual benefit to that? I mean, if you
On Wed, Jul 22, 2015 at 11:14 AM, Anand Jain wrote:
> From: Anand Jain
>
> This test case will test to confirm the replace works when
> the replacing source device has EIO errors.
>
> EIO condition is achieved using the DM device.
>
> Signed-off-by: Anand Jain
> ---
> v3->v4: rebase on latest xf
On Tue, May 5, 2015 at 8:03 PM, Anand Jain wrote:
> This test case tests if the device delete would work when
> the source device has failed with EIO errors.
>
> EIO errors are achieved usign the DM device.
>
> Also this test needs the latest btrfs-progs and kernel patch
Not patch, but patch set
On 7 August 2015 at 10:47, Sjoerd wrote:
> While we're at it: any idea why the default for SSD's is single for meta data
> as described on the wiki?
> (https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices#Filesystem_creation)
>
> I was looking for an answer why my SSD just had
Sjoerd posted on Fri, 07 Aug 2015 11:47:57 +0200 as excerpted:
> While we're at it: any idea why the default for SSD's is single for meta
> data as described on the wiki?
> (https://btrfs.wiki.kernel.org/index.php/
Using_Btrfs_with_Multiple_Devices#Filesystem_creation)
>
> I was looking for an an
On 2015-08-07 06:40, Mike Fleetwood wrote:
On 7 August 2015 at 10:47, Sjoerd wrote:
While we're at it: any idea why the default for SSD's is single for meta data
as described on the wiki?
(https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices#Filesystem_creation)
I was look
>> Qu Wenruo (3):
>> btrfs-progs: fsck: Print correct file hole
>> btrfs-progs: fsck: Fix a infinite loop on discount file extent repair
>> btrfs-progs: fsck-tests: Add test case for inode lost all its file
>> extent
>
> Applied, thank you both.
I tried to find a git repo with these patc
On Fri, Aug 07, 2015 at 04:05:44PM +0300, Robert Munteanu wrote:
> >> Qu Wenruo (3):
> >> btrfs-progs: fsck: Print correct file hole
> >> btrfs-progs: fsck: Fix a infinite loop on discount file extent repair
> >> btrfs-progs: fsck-tests: Add test case for inode lost all its file
> >> exte
On Fri, Aug 7, 2015 at 5:00 PM, David Sterba wrote:
> On Fri, Aug 07, 2015 at 04:05:44PM +0300, Robert Munteanu wrote:
>> >> Qu Wenruo (3):
>> >> btrfs-progs: fsck: Print correct file hole
>> >> btrfs-progs: fsck: Fix a infinite loop on discount file extent repair
>> >> btrfs-progs: fsck-tes
On Fri, Aug 07, 2015 at 05:17:34PM +0300, Robert Munteanu wrote:
> Thanks for the update. Reading it looks to me like the patches should be at
>
> http://repo.or.cz/w/btrfs-progs-unstable/devel.git/shortlog/refs/heads/devel
>
> but they don't seem to be . Am I long in the wrong place again :-)
On Fri, Aug 7, 2015 at 5:19 PM, David Sterba wrote:
> On Fri, Aug 07, 2015 at 05:17:34PM +0300, Robert Munteanu wrote:
>> Thanks for the update. Reading it looks to me like the patches should be at
>>
>>
>> http://repo.or.cz/w/btrfs-progs-unstable/devel.git/shortlog/refs/heads/devel
>>
>> but t
On Fri, Aug 7, 2015 at 2:30 AM, Patrik Lundquist
wrote:
> On 7 August 2015 at 00:17, Peter Foley wrote:
>> Hi,
>>
>> I have an btrfs volume that spans multiple disks (no raid, just
>> single), and earlier this morning I hit some hardware problems with
>> one of the disks.
>> I tried btrfs dev del
On 08/07/2015 03:05 AM, Chandan Rajendra wrote:
Checksums are applicable to sectorsize units. The current code uses
bio->bv_len units to compute and look up checksums. This works on machines
where sectorsize == PAGE_SIZE. This patch makes the checksum computation and
look up code to work with sec
On 08/07/2015 03:05 AM, Chandan Rajendra wrote:
The direct I/O read's endio and corresponding repair functions work on
page sized blocks. This commit adds the ability for direct I/O read to work on
subpagesized blocks.
Signed-off-by: Chandan Rajendra
---
fs/btrfs/inode.c | 96
On Friday 07 August 2015 11:40:24 Mike Fleetwood wrote:
> On 7 August 2015 at 10:47, Sjoerd wrote:
> > While we're at it: any idea why the default for SSD's is single for meta
> > data as described on the wiki?
> > (https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices
> > #Fil
On 08/07/2015 06:01 AM, Liu Bo wrote:
> Could you do 'echo w > /proc/sysrq-trigger' to gather the whole hang call
> stack?
Thanks a lot for the feedback. Full call stack output is attached
(pasting inline makes no sense due to the size of 2423 lines/135k).
In case VGER will strip attachments of
37 matches
Mail list logo
