At Sat, 23 Sep 2017 10:19:26 +0900,
Satoru Takeuchi wrote:
>
> At Wed, 20 Sep 2017 15:18:43 +0900,
> Qu Wenruo wrote:
> >
> > Commit 7dfb8be11b5d ("btrfs: Round down values which are written for
> > total_bytes_size") is fixing the unaligned device size caused by
> > adding/shrinking device.
> >
At Wed, 20 Sep 2017 15:18:43 +0900,
Qu Wenruo wrote:
>
> Commit 7dfb8be11b5d ("btrfs: Round down values which are written for
> total_bytes_size") is fixing the unaligned device size caused by
> adding/shrinking device.
>
> It added a new WARN_ON() when device size is unaligned.
> This is fine fo
On 2017年09月23日 08:48, Liu Bo wrote:
On Sat, Sep 23, 2017 at 08:46:55AM +0800, Qu Wenruo wrote:
On 2017年09月23日 07:36, Liu Bo wrote:
This uses a bool 'do_backup' to help understand this piece of code.
Signed-off-by: Liu Bo
---
This is based on a patch "Btrfs: do not backup tree roots when f
On Sat, Sep 23, 2017 at 09:49:38AM +0900, Satoru Takeuchi wrote:
> At Tue, 19 Sep 2017 17:50:09 -0600,
> Liu Bo wrote:
> >
> > This seems to be a leftover of commit cf8cddd38bab ("btrfs: don't
> > abuse REQ_OP_* flags for btrfs_map_block").
> >
> > It should use btrfs_op() helper to provide one o
On Sat, Sep 23, 2017 at 08:46:55AM +0800, Qu Wenruo wrote:
>
>
> On 2017年09月23日 07:36, Liu Bo wrote:
> > This uses a bool 'do_backup' to help understand this piece of code.
> >
> > Signed-off-by: Liu Bo
> > ---
> > This is based on a patch "Btrfs: do not backup tree roots when fsync".
> >
> >
At Tue, 19 Sep 2017 17:50:09 -0600,
Liu Bo wrote:
>
> This seems to be a leftover of commit cf8cddd38bab ("btrfs: don't
> abuse REQ_OP_* flags for btrfs_map_block").
>
> It should use btrfs_op() helper to provide one of 'enum btrfs_map_op'
> types.
>
> Signed-off-by: Liu Bo
Reviewed-by: Satoru
On 2017年09月23日 07:36, Liu Bo wrote:
This uses a bool 'do_backup' to help understand this piece of code.
Signed-off-by: Liu Bo
---
This is based on a patch "Btrfs: do not backup tree roots when fsync".
fs/btrfs/disk-io.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a
This uses a bool 'do_backup' to help understand this piece of code.
Signed-off-by: Liu Bo
---
This is based on a patch "Btrfs: do not backup tree roots when fsync".
fs/btrfs/disk-io.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
i
We had a bug in btrfs compression code which could end up with a
kernel panic.
This is adding a regression test for the bug and I've also sent a
kernel patch to fix the bug.
The patch is "Btrfs: fix kernel oops while reading compressed data".
Signed-off-by: Liu Bo
---
v2: - Fix ambiguous copyri
Am Freitag, 22. September 2017, 13:22:52 CEST schrieb Austin S. Hemmelgarn:
> > I'm not sure where Firefox puts its cache, I only use it on very rare
> > occasions. But I think it's going to .cache/mozilla last time looked
> > at it.
>
> I'm pretty sure that is correct.
FWIW, on my system Firefox
On Thu, Sep 21, 2017 at 02:39:52PM +1000, Dave Chinner wrote:
> On Wed, Sep 20, 2017 at 05:52:43PM -0600, Liu Bo wrote:
> > We had a bug in btrfs compression code which could end up with a
> > kernel panic.
> >
> > This is adding a regression test for the bug and I've also sent a
> > kernel patch
On Thu, Sep 21, 2017 at 03:03:45PM +0800, Lu Fengqi wrote:
> On Wed, Sep 20, 2017 at 05:52:43PM -0600, Liu Bo wrote:
> >We had a bug in btrfs compression code which could end up with a
> >kernel panic.
> >
> >This is adding a regression test for the bug and I've also sent a
> >kernel patch to fix t
The local bio_list may have pending bios when doing cleanup, it can
end up with memory leak if they don't get free'd.
Signed-off-by: Liu Bo
---
fs/btrfs/raid56.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/raid56.c b/fs/btrfs/raid56.c
inde
The LOGICAL_INO ioctl provides a backward mapping from extent bytenr and
offset (encoded as a single logical address) to a list of extent refs.
LOGICAL_INO complements TREE_SEARCH, which provides the forward mapping
(extent ref -> extent bytenr and offset, or logical address). These are
useful cap
Build-server workloads have hundreds of references per file after dedup.
Multiply by a few snapshots and we quickly exhaust the limit of 2730
references per extent that can fit into a 64K buffer.
Raise the limit to 16M to be consistent with other btrfs ioctls
(e.g. TREE_SEARCH_V2, FILE_EXTENT_SAME
Now that check_extent_in_eb()'s extent offset filter can be turned off,
we need a way to do it from userspace.
Add a 'flags' field to the btrfs_logical_ino_args structure to disable
extent offset filtering, taking the place of one of the existing
reserved[] fields.
Previous versions of LOGICAL_IN
Changelog:
v3-v2:
- Stricter check on reserved[] field - now must be all zero, or
userspace gets EINVAL. This prevents userspace from setting any
of the reserved bits without the kernel providing an unambiguous
interpretation of them, and doesn't require us to bur
2017-09-22 8:33 GMT+03:00 shally verma :
> On Wed, Sep 20, 2017 at 5:26 PM, Timofey Titovets
> wrote:
>> 2017-09-20 14:10 GMT+03:00 shally verma :
>>> Interesting part is I dont see "encoded" under flags. I couldn't
>>> understand if flags are retrieved from btrfs file metadata info. As
>>> you a
tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git
new-kill-btree-inode
head: 3264d40ac916ca952f0b85e39304b9199ff36d8b
commit: 3264d40ac916ca952f0b85e39304b9199ff36d8b [20/20] Btrfs: kill the
btree_inode
config: x86_64-randconfig-i0-201738 (attached as .config)
compile
tree: https://git.kernel.org/pub/scm/linux/kernel/git/josef/btrfs-next.git
new-kill-btree-inode
head: 3264d40ac916ca952f0b85e39304b9199ff36d8b
commit: a03edce0823e97312869c60933b37157c3b8866a [17/20] remove mapping from
balance_dirty_pages*()
config: x86_64-randconfig-x007-201738 (attached as
On 2017年09月22日 21:33, Austin S. Hemmelgarn wrote:
On 2017-09-22 08:32, Qu Wenruo wrote:
On 2017年09月22日 19:38, Austin S. Hemmelgarn wrote:
On 2017-09-22 06:39, Qu Wenruo wrote:
As I already stated in an other thread, if you want to shrink, do it
in another command line tool.
Do one thing and
On 2017-09-22 08:32, Qu Wenruo wrote:
On 2017年09月22日 19:38, Austin S. Hemmelgarn wrote:
On 2017-09-22 06:39, Qu Wenruo wrote:
As I already stated in an other thread, if you want to shrink, do it
in another command line tool.
Do one thing and do it simple. (Although Btrfs itself is already out
On 2017年09月22日 19:38, Austin S. Hemmelgarn wrote:
On 2017-09-22 06:39, Qu Wenruo wrote:
As I already stated in an other thread, if you want to shrink, do it
in another command line tool.
Do one thing and do it simple. (Although Btrfs itself is already out
of the UNIX way)
Unless I'm reading t
On 2017-09-22 06:39, Qu Wenruo wrote:
As I already stated in an other thread, if you want to shrink, do it in another
command line tool.
Do one thing and do it simple. (Although Btrfs itself is already out of the
UNIX way)
Unless I'm reading the code wrong, the shrinking isn't happening in a
s
On 2017-09-21 16:10, Kai Krakow wrote:
Am Wed, 20 Sep 2017 07:46:52 -0400
schrieb "Austin S. Hemmelgarn" :
Fragmentation: Files with a lot of random writes can become
heavily fragmented (1+ extents) causing excessive multi-second
spikes of CPU load on systems with an SSD or large amou
As I already stated in an other thread, if you want to shrink, do it in another
command line tool.
Do one thing and do it simple. (Although Btrfs itself is already out of the
UNIX way)
It may be offline shrink/balance. But not to further complexing the --rootdir
option now.
And you also said t
+WARNING: Before v4.14 btrfs-progs, *--rootdir* will shrink the filesystem,
+prevent user to make use of the remaining space.
+In v4.14 btrfs-progs, this behavior is changed, and will not shrink the fs.
+The result should be the same as `mkfs`, `mount` and then `cp -r`. +
Hmm well. Shrink to
On Mon, Sep 18, 2017 at 04:11:09PM +0800, Gu Jinxiang wrote:
> Resovle the inconsistent of mount option.
> Btrfs use MOUNT_OPTIONS for both scrath_dev and test_dev. Change to
> MOUNT_OPTIONS for scratch mount, and TEST_FS_MOUNT_OPTS for test dev
> mount.
>
> Signed-off-by: Gu Jinxiang
> ---
> As
shally verma posted on Fri, 22 Sep 2017 12:01:32 +0530 as excerpted:
> In response to my question in another thread:
>> Is there any command that i can run to confirm file has been compressed?
>
> I've gotten response from Duncan:
>>>There is the quite recently posted (and actively updated since
29 matches
Mail list logo