On 2019/9/14 3:46, Jaegeuk Kim wrote:
> https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev&id=ebef4d7eda0d06a6ab6dc0f9e9f848276e605962
Reviewed-by: Chao Yu
Thanks,
>
> Merged. Thanks,
>
> On 09/11, Goldwyn Rodrigues wrote:
>> From: Goldwyn Rodrigues
>>
>> This is
Quoting Zygo Blaxell :
On Fri, Sep 13, 2019 at 09:28:49PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> On Fri, Sep 13, 2019 at 05:25:20AM -0400, General Zed wrote:
> >
> > Quoting General Zed :
> >
> > > Quoting Zygo Blaxell :
> > >
> > > > On Thu, Sep 12, 2019 at 08:26:04PM -0400, Ge
Quoting Zygo Blaxell :
On Fri, Sep 13, 2019 at 09:50:38PM -0400, General Zed wrote:
Quoting Zygo Blaxell :
> On Fri, Sep 13, 2019 at 01:05:52AM -0400, General Zed wrote:
> >
> > Quoting Zygo Blaxell :
> >
> > > On Thu, Sep 12, 2019 at 08:26:04PM -0400, General Zed wrote:
> > > >
> > > > Quo
I'm looking at turning an old PC into a backup server / NAS. I could
have been bitten by the recent regression if it had caused issue with my
backup USB drive which is also using btrfs.
If I am running a recent 5.1x or 5.2.x kernel on my main machine and the
backup/NAS machine is running 4.19.72
On Sun, Sep 15, 2019 at 1:46 PM James Harvey wrote:
>
> For several weeks, I've had an enormous amount of frustration when
> under heavy I/O load with a filesystem putting processes using it into
> permanent uninterruptible sleep. Sometimes the filesystem allows
> reads and only locks up writing
On Sun, Sep 15, 2019 at 8:46 AM James Harvey wrote:
> ...
> Because the heavy I/O involves mongodb, and it really doesn't do well
> in a crash, and I wasn't sure if there could be any residual
> filesystem corruption, I just decided to create a new VM and rebuild
> the database from its source mat
On Sun, Sep 15, 2019 at 10:21:14AM +0100, Filipe Manana wrote:
> On Sun, Sep 15, 2019 at 8:32 AM Qu Wenruo wrote:
> >
> > Add a test case where falloc is called on multiple holes with qgroup
> > enabled.
> >
> > This can cause qgroup reserved data space leak and false EDQUOT error
> > even we're n
For several weeks, I've had an enormous amount of frustration when
under heavy I/O load with a filesystem putting processes using it into
permanent uninterruptible sleep. Sometimes the filesystem allows
reads and only locks up writing processes, sometimes it locks up both.
I really, really want t
On Sun, Sep 15, 2019 at 8:32 AM Qu Wenruo wrote:
>
> Add a test case where falloc is called on multiple holes with qgroup
> enabled.
>
> This can cause qgroup reserved data space leak and false EDQUOT error
> even we're not reaching the limit.
>
> The fix is titled:
> "btrfs: qgroup: Fix the wrong
Add a test case where falloc is called on multiple holes with qgroup
enabled.
This can cause qgroup reserved data space leak and false EDQUOT error
even we're not reaching the limit.
The fix is titled:
"btrfs: qgroup: Fix the wrong target io_tree when freeing
reserved data space"
Signed-off-by:
On 2019/9/15 下午12:36, Eryu Guan wrote:
> On Fri, Sep 13, 2019 at 09:51:51AM +0800, Qu Wenruo wrote:
>> Add a test case where falloc is called on multiple holes with qgroup
>> enabled.
>>
>> This can cause qgroup reserved data space leak and false EDQUOT error
>> even we're not reaching the limit.
11 matches
Mail list logo