I use WordPress.org, not WordPress.com, for most of what I subscribe to.

I think it is a bit my own fault, for not explaining in a clear way, what the difference is between WordPress.com and WordPress.org .

WordPress.com is a specialized blog-hosting site, on which members can write their blogs, but which runs on professionally-maintained servers, by WordpRess.com .

But, the people behind this service have also made the PHP Scripts available for free, that run on the server, and that cause the HTML to be generated, which causes proper WordPress blogs to appear on the browser of the reader. People may download those, and may upload them to whatever Web-server they have access to, provided that that Web-hosting service, also supports the running of server-side scripts, by the Web-hosting service members. Some Web-hosting services put a lot of restrictions on what their members may publish, such as static HTML Pages only, or such as no access to any MySQL server, the latter of which WordPress.org uses actually to store the blogs.

And so, because this support-factor is the main part of the expenses incurred by WordPress.com, I will assume that sharing their core scripts poses no perceived threat to them. Their main expense is not, that core set of PHP Scripts. But, because an individual may have problems setting all this up as well, there is an associated Web-site, namely WordPress.org, where independently-hosted WordPress users can go for tech support, and to download plug-ins.

Momentary Software Update Today

By default, “WordPress” blogs are actually stored on a “MySQL server”, so that actual ‘PHP’ scripts access this database, and render it as HTML from the Web server.

Today the Linux package manager installed an update to the MySQL server running on this box. This also triggered a restart of the server-instance running centrally as user ‘root‘. Therefore, access to my blog may have been affected briefly, from 18h50 until about 18h55 today.

I apologize for any inconvenience.

Dirk

Since I started this blog, my Linux O/S has already installed Unattended Upgrades, to packages that are needed to display the blog correctly. This includes upgrades to the Apache server, as well as to the MySQL database engine. In each case, the blog would have been unable to load properly for up to two minutes. Yet, I have not allowed this for any WordPress.org plugins.

An Aspect to Hugetlbfs, which Many Sites Omit

I was recently troubleshooting the question of Huge Pages under Linux, which are pages of virtual memory with a size of 2MB each, instead of 4KB. And I was interested in the question of statically-allocated ones, even though modern, 64-bit Linux systems also offer Transparent Huge Pages. There was a gap in what was posted online, concerning the possibility or need to mount an actual ‘hugetlbfs’ file system, according to whether specific programs use one.

Under systems such as my own, as soon as the system boots with hugetlbfs enabled – i.e. a non-zero number of them – the kernel automatically creates a mount-point at ‘/dev/hugepages’. This mount-point is created without any administrator ‘fstab’ entry, and belongs to user and group ‘root’. According to some needs, such a mount-point would better be created as belonging to a specific group, and as having the option ‘mode=1770′ set. And so before checking the default behavior of my kernel, I also created a suitable mount-point at ‘/mnt/hugepages’. The question remained in my mind, of whether any way exists to give the automatic mount-point at ‘/dev/hugepages’ my custom options. And the answer seems to be No.

Here’s what the online documentation forgets to mention:

If you have a program which requires such a mount-point, there will be a line in its config file, that states where it’s located. Any files created in such a mount-point will then consume statically-allocated huge pages of RAM.

Because MySQL is not an example of a program that requires this, its config file also requires no line, to tell it which mount-point to use. MySQL uses memory-allocation functions directly, to ask the kernel for huge pages.

I suppose that it does no real harm, if there is more than one hugetlbfs mounted at any time, as long as the unneeded one is not wasting any pages, let’s say as long as absolutely no files are being created in the unused mount-point. And then if we need to, we can in fact give our custom hugetlbfs mount-point whatever properties we think it should have, via the mount options or the fstab.

Because I didn’t need the one I had created, I simply got rid of it again. Besides which, the fact that one is automatically created at ‘/dev/hugepages’ these days, suggests that future programs that need it, will already be configured to look for it there. And then it would also make sense, if those programs were able to deal with the fact that that one belongs to user and group ‘root’.

Dirk