On Mon, Feb 12, 2018 at 07:23:05AM -0800, Liu Bo wrote:
> On Thu, Feb 08, 2018 at 08:57:39PM -0800, Darrick J. Wong wrote:
> > On Mon, Feb 05, 2018 at 04:15:02PM -0700, Liu Bo wrote:
> > > Btrfs tries its best to tolerate write errors, but kind of silently
> > > (except some messages in kernel
On Mon, Feb 12, 2018 at 07:39:02PM +0200, Nikolay Borisov wrote:
>
>
> On 12.02.2018 16:17, Liu Bo wrote:
> > On Tue, Feb 06, 2018 at 11:11:55AM +0200, Nikolay Borisov wrote:
[...]
> >>
> >> Use list_for_each_entry_safe to make it more apparent you are going to
> >> be removing from the list.
On 12.02.2018 16:17, Liu Bo wrote:
> On Tue, Feb 06, 2018 at 11:11:55AM +0200, Nikolay Borisov wrote:
>>
>>
>> On 6.02.2018 01:15, Liu Bo wrote:
>>> Btrfs tries its best to tolerate write errors, but kind of silently
>>> (except some messages in kernel log).
>>>
>>> For raid1 and raid10, this
On Fri, Feb 09, 2018 at 06:02:01PM +0100, Goffredo Baroncelli wrote:
> On 02/08/2018 08:07 PM, Liu Bo wrote:
> > On Thu, Feb 08, 2018 at 07:52:05PM +0100, Goffredo Baroncelli wrote:
> >> On 02/06/2018 12:15 AM, Liu Bo wrote:
> >> [...]
> >>> One way to mitigate the data loss pain is to expose 'bad
On Thu, Feb 08, 2018 at 08:57:39PM -0800, Darrick J. Wong wrote:
> On Mon, Feb 05, 2018 at 04:15:02PM -0700, Liu Bo wrote:
> > Btrfs tries its best to tolerate write errors, but kind of silently
> > (except some messages in kernel log).
> >
> > For raid1 and raid10, this is usually not a problem
On Thu, Feb 08, 2018 at 05:47:46PM +0800, Anand Jain wrote:
>
>
> On 02/06/2018 07:15 AM, Liu Bo wrote:
> > Btrfs tries its best to tolerate write errors, but kind of silently
> > (except some messages in kernel log).
> >
> > For raid1 and raid10, this is usually not a problem because there is
On Tue, Feb 06, 2018 at 11:11:55AM +0200, Nikolay Borisov wrote:
>
>
> On 6.02.2018 01:15, Liu Bo wrote:
> > Btrfs tries its best to tolerate write errors, but kind of silently
> > (except some messages in kernel log).
> >
> > For raid1 and raid10, this is usually not a problem because there
On 02/08/2018 08:07 PM, Liu Bo wrote:
> On Thu, Feb 08, 2018 at 07:52:05PM +0100, Goffredo Baroncelli wrote:
>> On 02/06/2018 12:15 AM, Liu Bo wrote:
>> [...]
>>> One way to mitigate the data loss pain is to expose 'bad chunks',
>>> i.e. degraded chunks, to users, so that they can use 'btrfs
On Mon, Feb 05, 2018 at 04:15:02PM -0700, Liu Bo wrote:
> Btrfs tries its best to tolerate write errors, but kind of silently
> (except some messages in kernel log).
>
> For raid1 and raid10, this is usually not a problem because there is a
> copy as backup, while for parity based raid setup,
On 2018年02月09日 03:07, Liu Bo wrote:
> On Thu, Feb 08, 2018 at 07:52:05PM +0100, Goffredo Baroncelli wrote:
>> On 02/06/2018 12:15 AM, Liu Bo wrote:
>> [...]
>>> One way to mitigate the data loss pain is to expose 'bad chunks',
>>> i.e. degraded chunks, to users, so that they can use 'btrfs
On Thu, Feb 08, 2018 at 07:52:05PM +0100, Goffredo Baroncelli wrote:
> On 02/06/2018 12:15 AM, Liu Bo wrote:
> [...]
> > One way to mitigate the data loss pain is to expose 'bad chunks',
> > i.e. degraded chunks, to users, so that they can use 'btrfs balance'
> > to relocate the whole chunk and
On 02/06/2018 12:15 AM, Liu Bo wrote:
[...]
> One way to mitigate the data loss pain is to expose 'bad chunks',
> i.e. degraded chunks, to users, so that they can use 'btrfs balance'
> to relocate the whole chunk and get the full raid6 protection again
> (if the relocation works).
[...]
[...]
>
On 02/06/2018 07:15 AM, Liu Bo wrote:
Btrfs tries its best to tolerate write errors, but kind of silently
(except some messages in kernel log).
For raid1 and raid10, this is usually not a problem because there is a
copy as backup, while for parity based raid setup, i.e. raid5 and
raid6, the
On 2018年02月08日 06:57, Liu Bo wrote:
> On Tue, Feb 06, 2018 at 09:28:14AM +0800, Qu Wenruo wrote:
>>
>>
>> On 2018年02月06日 07:15, Liu Bo wrote:
>>> Btrfs tries its best to tolerate write errors, but kind of silently
>>> (except some messages in kernel log).
>>>
>>> For raid1 and raid10, this is
On Tue, Feb 06, 2018 at 09:28:14AM +0800, Qu Wenruo wrote:
>
>
> On 2018年02月06日 07:15, Liu Bo wrote:
> > Btrfs tries its best to tolerate write errors, but kind of silently
> > (except some messages in kernel log).
> >
> > For raid1 and raid10, this is usually not a problem because there is a
>
On 6.02.2018 01:15, Liu Bo wrote:
> Btrfs tries its best to tolerate write errors, but kind of silently
> (except some messages in kernel log).
>
> For raid1 and raid10, this is usually not a problem because there is a
> copy as backup, while for parity based raid setup, i.e. raid5 and
>
On 2018年02月06日 07:15, Liu Bo wrote:
> Btrfs tries its best to tolerate write errors, but kind of silently
> (except some messages in kernel log).
>
> For raid1 and raid10, this is usually not a problem because there is a
> copy as backup, while for parity based raid setup, i.e. raid5 and
>
Btrfs tries its best to tolerate write errors, but kind of silently
(except some messages in kernel log).
For raid1 and raid10, this is usually not a problem because there is a
copy as backup, while for parity based raid setup, i.e. raid5 and
raid6, the problem is that, if a write error occurs
18 matches
Mail list logo
