From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Andrei Banu <andrei.banu@redhost.ro>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Weird jbd2 I/O load
Date: Tue, 22 Oct 2013 00:55:20 +0800 [thread overview]
Message-ID: <52655C78.4080507@gmail.com> (raw)
In-Reply-To: <5265392D.1020500@redhost.ro>
On 10/21/2013 10:24 PM, Andrei Banu wrote:
> Hi Zheng,
>
> Thank you for your reply. We can make this test and if it doesn't help
> we'll re-enable
> the barrier but first I need to ask a few questions:
>
> 1. /dev/md2 is mounted on /. So your command should look like this?
>
> $ mount -t ext4 -o remount,barrier=0 /dev/md2 /
Yes.
>
> In /etc/fstab I have other parameters as well:
> noatime,usrjquota=quota.user,jqfmt=vfsv0
> Do I also add these like this:
>
> $ mount -t ext4 -o
> remount,barrier=0,noatime,usrjquota=quota.user,jqfmt=vfsv0 /dev/md2 /
If I remember correctly, this command is OK. But frankly I don't do the
test. I am not sure all these options will pass when you remount a
partition.
>
> 2. Can the command above be run on an active (very active) cPanel server?
Sorry, I am not familiar with cPanel server. But if your previous
testings run on a server under a heavy pressure. It quite impacts the
result because disk bandwidth is occupied by this process.
>
> 3. How do I re-enable the barrier?
sudo mount -t ext4 -o remount,barrier=1 ${DEV} ${MNT}
>
> 4. What is the probability of data loss in case of cold reboot?
After disabling barrier, the system couldn't ensure that the dirty data
has been written into the disk medium if your device couldn't support
FUA command. So I just want to make sure that your SSD can not handle
barrier command properly. *Please do not use 'barrier=0' in your
product system*.
- Zheng
>
> Thanks!
>
> On 10/21/2013 4:53 PM, Zheng Liu wrote:
>> Hi Andrei,
>>
>> Could you please disable barrier for ext4 and try your 'dd' test again?
>> $ sudo mount -t ext4 -o remount,barrier=0 ${DEV} ${MNT}
>>
>> *WARNING: you could lost your data with barrier=0 when you get a power
>> failure or cold reset.*
>>
>> We have met a similar problem that is because some SSDs couldn't handle
>> barrier command properly.
>>
>> Regards,
>> - Zheng
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-10-21 16:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-15 21:41 Weird jbd2 I/O load Andrei Banu
2013-10-21 13:53 ` Zheng Liu
2013-10-21 14:24 ` Andrei Banu
2013-10-21 16:55 ` Zheng Liu [this message]
2013-10-21 17:11 ` Zheng Liu
2013-10-21 17:42 ` Andrei Banu
2013-10-22 2:57 ` Zheng Liu
2013-10-22 7:22 ` Andrei Banu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52655C78.4080507@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=andrei.banu@redhost.ro \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox