Bug #35163 | memlock make raw disk partition unaccessable | ||
---|---|---|---|
Submitted: | 8 Mar 2008 16:04 | Modified: | 30 Oct 2008 17:57 |
Reporter: | Bin Tian | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Documentation | Severity: | S3 (Non-critical) |
Version: | 5.0.32 | OS: | Linux |
Assigned to: | Paul DuBois | CPU Architecture: | Any |
[8 Mar 2008 16:04]
Bin Tian
[8 Mar 2008 16:21]
Bin Tian
Adding root user to group which can access the disk may have security issues. And it doesn't work during the system booting. Because the booting process won't call `init_groups`. It works only if the root user login and manually start mysql. You can modify mysql startup scripts and use sudo to start mysqld. Then it will work during system booting.
[10 Mar 2008 13:28]
Heikki Tuuri
Why do you want to use raw partitions? Usually, there is no performance benefit. Management of raw partitions is more diffult than files. Regards, Heikki
[11 Mar 2008 0:19]
Bin Tian
For your question: I have another server which connected to SAN. I'm planning to allocate some paticular LUNs to mysql as innodb tablespace. It's quite easy to manage LUNs. Before doing that, I'my tring to do some tests on a normal PC server (not connected to SAN). I use partitions for LUNs. My question: What you said is quite different from MYSQL manual. It says `a significant performance gain can be achieved by placing InnoDB data files and log files on raw devices or on a separate direct I/O UFS filesystem (using mount option forcedirectio; see mount_ufs(1M))`. Do I have misunderstanding or is there any other any other tips I didn't find? For the problem: When memlock is enable, mysqld.cc calls set_effective_user instead of set_user. To correct it, we can call initgroups in set_effective_user as in set_user. Maybe we should getgroups before initgroups (to get root user's groups), after call initgroups, call getgroups again (to get mysql user's groups). Finally, we merge that and call setgroups.
[11 Mar 2008 14:43]
Heikki Tuuri
Bin, you are right that the manual is incorrect about the benefits of raw disk partitions. I am a bit worried if you use a little-used feature in a SAN. Our impression is that SAN's usually are reliable persistent storage; that is, there are not too blatant bugs in the implementation of fsync() there. But a little-used feature might not be as reliable. Note that we discourage people from using NFS, because too many reliability problems have been reported over years. Paul, I am setting this bug report to the 'Documenting' status. Please remove from the manual the claims that raw disk partitions give better performance. I have seen 1 % improvement in some benchmarks. Regards, Heikki
[11 Mar 2008 14:44]
Heikki Tuuri
Bin, should we also add something about the memlock to the manual? --Heikki
[12 Mar 2008 0:18]
Bin Tian
Heikki, Thanks for your explanation. You are right, reliability is more important than performance in some situation. memlock option do have some filesystem access problem. Under Linux and some other os, a process has supplementary group IDs in addition to the effective group ID. The OS use it to determining file access permissions. somebody maybe use this feature along with mysql to get more flexibility. But if they enable memlock, they would be confused why it doesn't work. The reason is that when memlock is enabled, mysqld change only the process' effective user&group, the supplementary group IDs are leaved unchanged. In my opion, we should fix it rather than document it. BTW: This bug's category should be changed to `Server`. It's not innodb's problem.
[30 Oct 2008 17:57]
Paul DuBois
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products. * Pointed out that --memlock affects raw partition access * Pointed out that raw partitions do not necessarily improve performance