Hi Changwei,
Thanks for quick repling, Gang and I are thinking about how to notice
user to recover this problem, and later I will post patch v2.
thanks
Jun
On 2018/1/27 13:17, Changwei Ge wrote:
> Hi Jun,
>
> On 2018/1/27 11:52, piaojun wrote:
>> Hi Jan and Changwei,
>>
>> I will describle the
Hi Jun,
On 2018/1/27 11:52, piaojun wrote:
> Hi Jan and Changwei,
>
> I will describle the scenario again as below:
>
> 1. The bhs of truncate log and extent rec are submitted to jbd2 area
> successfully.
> 2. Then write-back thread of device help flush the bhs to disk but
> encounter
Hi Jan and Changwei,
I will describle the scenario again as below:
1. The bhs of truncate log and extent rec are submitted to jbd2 area
successfully.
2. Then write-back thread of device help flush the bhs to disk but
encounter write error due to abnormal storage link.
3. After a while the
Hi Jun,
>>>
> Hi Gang,
>
> Filesystem won't become readonly and journal remains normal,
How does the user aware this kind of issue happen? watch the kernel message?
but some users do not like watch the kernel message except
there is serious problem (e.g. crash).
so this problem needs
Hi Gang,
On 2018/1/26 10:16, Gang He wrote:
> Hi Jun,
>
>
>> Hi Gang,
>>
>> Filesystem won't become readonly and journal remains normal,
> How does the user aware this kind of issue happen? watch the kernel message?
> but some users do not like watch the kernel message except
> there
On 2018/1/26 9:45, piaojun wrote:
> Hi Changwei,
>
> On 2018/1/26 9:00, Changwei Ge wrote:
>> Hi Jun,
>> Good morning:-)
>>
>> On 2018/1/25 20:45, piaojun wrote:
>>> Hi Changwei,
>>>
>>> On 2018/1/25 20:30, Changwei Ge wrote:
Hi Jun,
On 2018/1/25 20:18, piaojun wrote:
> Hi
Hi Changwei,
On 2018/1/26 9:00, Changwei Ge wrote:
> Hi Jun,
> Good morning:-)
>
> On 2018/1/25 20:45, piaojun wrote:
>> Hi Changwei,
>>
>> On 2018/1/25 20:30, Changwei Ge wrote:
>>> Hi Jun,
>>>
>>> On 2018/1/25 20:18, piaojun wrote:
Hi Changwei,
On 2018/1/25 19:59, Changwei Ge
Hi Jun,
Good morning:-)
On 2018/1/25 20:45, piaojun wrote:
> Hi Changwei,
>
> On 2018/1/25 20:30, Changwei Ge wrote:
>> Hi Jun,
>>
>> On 2018/1/25 20:18, piaojun wrote:
>>> Hi Changwei,
>>>
>>> On 2018/1/25 19:59, Changwei Ge wrote:
Hi Jun,
On 2018/1/25 10:41, piaojun wrote:
>
Hi Jun,
On 2018/1/25 10:41, piaojun wrote:
> We should not reuse the dirty bh in jbd2 directly due to the following
> situation:
>
> 1. When removing extent rec, we will dirty the bhs of extent rec and
Quick questions:
Do you mean current code puts modifying extent records belonging to a certain
Hi Changwei,
On 2018/1/25 20:30, Changwei Ge wrote:
> Hi Jun,
>
> On 2018/1/25 20:18, piaojun wrote:
>> Hi Changwei,
>>
>> On 2018/1/25 19:59, Changwei Ge wrote:
>>> Hi Jun,
>>>
>>> On 2018/1/25 10:41, piaojun wrote:
We should not reuse the dirty bh in jbd2 directly due to the following
Hi Jun,
On 2018/1/25 20:18, piaojun wrote:
> Hi Changwei,
>
> On 2018/1/25 19:59, Changwei Ge wrote:
>> Hi Jun,
>>
>> On 2018/1/25 10:41, piaojun wrote:
>>> We should not reuse the dirty bh in jbd2 directly due to the following
>>> situation:
>>>
>>> 1. When removing extent rec, we will dirty
Hi Gang,
Filesystem won't become readonly and journal remains normal, so this
problem needs user umount and mount again to recover. And I'm thinking
about if we should set readonly to notice user.
thanks,
Jun
On 2018/1/25 16:40, Gang He wrote:
> Hi Jun,
>
> If we return -EIO here, what is the
Hi Changwei,
On 2018/1/25 19:59, Changwei Ge wrote:
> Hi Jun,
>
> On 2018/1/25 10:41, piaojun wrote:
>> We should not reuse the dirty bh in jbd2 directly due to the following
>> situation:
>>
>> 1. When removing extent rec, we will dirty the bhs of extent rec and
> Quick questions:
> Do you mean
Hi Jun,
If we return -EIO here, what is the consequence?
make the journal aborted and file system will become read-only?
Thanks
Gang
>>>
> We should not reuse the dirty bh in jbd2 directly due to the following
> situation:
>
> 1. When removing extent rec, we will dirty the bhs of extent rec
14 matches
Mail list logo
