> On 28 Jun 2019, at 1:58 PM, Qu Wenruo wrote:
>
>
>
> On 2019/6/28 上午10:47, Anand Jain wrote:
>> On 27/6/19 10:58 PM, David Sterba wrote:
>>> On Tue, Jun 25, 2019 at 04:24:57PM +0800, Qu Wenruo wrote:
Ping?
This patch should fix the problem of compressed extent even when
>>>
> On 28 Jun 2019, at 2:39 PM, Naohiro Aota wrote:
>
> On 2019/06/28 12:56, Anand Jain wrote:
>> On 7/6/19 9:10 PM, Naohiro Aota wrote:
>>> When in HMZONED mode, make sure that device super blocks are located in
>>> randomly writable zones of zoned block devices. That is, do not write super
>>>
On 2019/06/28 12:56, Anand Jain wrote:
> On 7/6/19 9:10 PM, Naohiro Aota wrote:
>> When in HMZONED mode, make sure that device super blocks are located in
>> randomly writable zones of zoned block devices. That is, do not write super
>> blocks in sequential write required zones of host-managed zone
On 2019/6/28 上午11:28, Anand Jain wrote:
> On 28/6/19 10:44 AM, Qu Wenruo wrote:
>>
>>
>> On 2019/6/28 上午10:26, Anand Jain wrote:
>>> At the time mkfs.btrfs the device id and stripe index gets reversed as
>>> shown in [1]. This patch helps to keep them in order at the time of
>>> mkfs.btrfs. And m
On 2019/6/28 上午10:47, Anand Jain wrote:
> On 27/6/19 10:58 PM, David Sterba wrote:
>> On Tue, Jun 25, 2019 at 04:24:57PM +0800, Qu Wenruo wrote:
>>> Ping?
>>>
>>> This patch should fix the problem of compressed extent even when
>>> nodatasum is set.
>>>
>>> It has been one year but we still didn'
On 27.06.19 г. 20:00 ч., fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Move the code that is responsible for dropping extents in a range out of
> btrfs_punch_hole() into a new helper function, btrfs_punch_hole_range(),
> so that later it can be used by the reflinking (extent cloning and
On 7/6/19 9:10 PM, Naohiro Aota wrote:
When in HMZONED mode, make sure that device super blocks are located in
randomly writable zones of zoned block devices. That is, do not write super
blocks in sequential write required zones of host-managed zoned block
devices as update would not be possible.
On Thu, Jun 27, 2019 at 10:47:31PM +0100, Filipe Manana wrote:
> On Thu, Jun 27, 2019 at 9:28 PM Darrick J. Wong
> wrote:
> >
> > On Thu, Jun 27, 2019 at 06:00:30PM +0100, fdman...@kernel.org wrote:
> > > From: Filipe Manana
> > >
> > > Test that if we clone a file with some large extents into a
On 28/6/19 10:44 AM, Qu Wenruo wrote:
On 2019/6/28 上午10:26, Anand Jain wrote:
At the time mkfs.btrfs the device id and stripe index gets reversed as
shown in [1]. This patch helps to keep them in order at the time of
mkfs.btrfs. And makes it easier to debug.
Before:
Stripe 0 is on devid 2; St
On 27/6/19 10:58 PM, David Sterba wrote:
On Tue, Jun 25, 2019 at 04:24:57PM +0800, Qu Wenruo wrote:
Ping?
This patch should fix the problem of compressed extent even when
nodatasum is set.
It has been one year but we still didn't get a conclusion on where
force_compress should behave.
Note t
On 2019/6/28 上午10:26, Anand Jain wrote:
> At the time mkfs.btrfs the device id and stripe index gets reversed as
> shown in [1]. This patch helps to keep them in order at the time of
> mkfs.btrfs. And makes it easier to debug.
>
> Before:
> Stripe 0 is on devid 2; Stipe 1 is on devid 1;
>
> ./m
At the time mkfs.btrfs the device id and stripe index gets reversed as
shown in [1]. This patch helps to keep them in order at the time of
mkfs.btrfs. And makes it easier to debug.
Before:
Stripe 0 is on devid 2; Stipe 1 is on devid 1;
./mkfs.btrfs -fq -draid1 -mraid1 /dev/sdb /dev/sdc && btrfs i
On 2019/6/27 下午10:58, David Sterba wrote:
> On Tue, Jun 25, 2019 at 04:24:57PM +0800, Qu Wenruo wrote:
>> Ping?
>>
>> This patch should fix the problem of compressed extent even when
>> nodatasum is set.
>>
>> It has been one year but we still didn't get a conclusion on where
>> force_compress sh
On Thu, Jun 27, 2019 at 9:28 PM Darrick J. Wong wrote:
>
> On Thu, Jun 27, 2019 at 06:00:30PM +0100, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > Test that if we clone a file with some large extents into a file that has
> > many small extents, when the fs is nearly full, the clone o
On Thu, Jun 27, 2019 at 06:00:30PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Test that if we clone a file with some large extents into a file that has
> many small extents, when the fs is nearly full, the clone operation does
> not fail and produces the correct result.
>
> This
From: Filipe Manana
Test that if we clone a file with some large extents into a file that has
many small extents, when the fs is nearly full, the clone operation does
not fail and produces the correct result.
This is motivated by a bug found in btrfs wich is fixed by the following
patches for th
From: Filipe Manana
When cloning extents (or deduplicating) we create a transaction with a
space reservation that considers we will drop or update a single file
extent item of the destination inode (that we modify a single leaf). That
is fine for the vast majority of scenarios, however it might h
From: Filipe Manana
Move the code that is responsible for dropping extents in a range out of
btrfs_punch_hole() into a new helper function, btrfs_punch_hole_range(),
so that later it can be used by the reflinking (extent cloning and dedup)
code to fix a ENOSPC bug.
Signed-off-by: Filipe Manana
On Tue, Jun 18, 2019 at 09:01:35AM +, Naohiro Aota wrote:
> On 2019/06/18 7:53, David Sterba wrote:
> > On Fri, Jun 07, 2019 at 10:10:15PM +0900, Naohiro Aota wrote:
> >> When in HMZONED mode, make sure that device super blocks are located in
> >> randomly writable zones of zoned block devices.
On Tue, Jun 18, 2019 at 08:49:00AM +, Naohiro Aota wrote:
> On 2019/06/18 7:29, David Sterba wrote:
> > On Fri, Jun 07, 2019 at 10:10:13PM +0900, Naohiro Aota wrote:
> >> + u64 unusable;
> >
> > 'unusable' is specific to the zones, so 'zone_unusable' would make it
> > clear. The terminilogy a
On Tue, Jun 18, 2019 at 06:42:09AM +, Naohiro Aota wrote:
> >> + device->seq_zones = kcalloc(BITS_TO_LONGS(device->nr_zones),
> >> + sizeof(*device->seq_zones), GFP_KERNEL);
> >
> > What's the expected range for the allocation size? There's one bit per
> > zone, s
On Tue, Jun 25, 2019 at 04:24:57PM +0800, Qu Wenruo wrote:
> Ping?
>
> This patch should fix the problem of compressed extent even when
> nodatasum is set.
>
> It has been one year but we still didn't get a conclusion on where
> force_compress should behave.
Note that pings to patches sent year
Hi,
I am very very sorry about that.
Because the my thunderbirds app always sends email with HTML,
which is rejected by linux-btrfs@vger.kernel.org. So I send a few.
I didn't notice you received email again and again.
But now, all is normal.
Sorry about that again.
--Hongzhi
On 6/27/19
Hi!
Looks like something is wrong with your email setup, you were sending
slightly modified versions of this email every few minutes. Please do
not spam us.
--
Cyril Hrubis
chru...@suse.cz
Hi friends,
*Description:*
One LTP testcase, fs_fill.c, fails on btrfs with kernel error:
"BTRFS warning (device loop0): could not allocate space for a delete;
will truncate on mount".
I found the loop block device formatted with btrfs roughly*rangs from
460M to 560M* will cause the error
On 6/26/19 6:47 PM, David Sterba wrote:
> On Tue, Jun 25, 2019 at 08:07:25PM +0200, Hans van Kranenburg wrote:
>> Hi,
>>
>> On 6/25/19 6:09 PM, David Sterba wrote:
>>> Hi,
>>>
>>> I'd like to get some feedback on the json output, the overall structure
>>> of the information and naming.
>>>
>>> Code
26 matches
Mail list logo
