David Scherfgen's questions

I want to prevent Apache from logging "File does not exist" errors for certain irrelevant non-existing files that are often requested, such as "apple-touch-icon-120x120.png". These log entries clutter my log and make it difficult to see "real" problems. This is what I came up with:

RewriteCond %{REQUEST_URI} ^/apple-touch-icon(-\d+x\d+)?(-precomposed)?\.png$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^ - [redirect=404]

The idea: If the file requested isn't a regular file and it isn't a symbolic link either, the RewriteRule will cause the error not to be logged. That kind of works.

Now I'm facing the following problem: If I actually create a symbolic link named "apple-touch-icon-120x120.png", then my RewriteRule still fires and I get 404. Without the rule or when I make the file a regular file and not a symbolic link, the file is served correctly. I thought that by using the !-l flag I could make my rule fire only if the requested file is not a regular file and it is not a symbolic link either. But that doesn't seem to work ...

I don't see anything suspicious in Apache's error log. What might I be doing wrong here?

I have a pair of 480 GB "Datacenter" SSDs (SAMSUNG MZ7LM480HMHQ-00005) that will make up a ZFS pool in a mirroring configuration. The pool's only content will be a ZFS volume (ZVOL) for a virtual machine. However, the ZVOL will only be 400 GB in size, leaving 80 GB of unused space on each SSD.

I'd like the SSDs to make the best use of their unused space, allowing them to use it for reducing the wearing of the flash memory. What would be the best way to achieve this?

1. Simply use the whole SSDs for the pool?

2. Create a 400 GB partition on each SSD and use these for the pool, leaving 80 GB unpartitioned?

3. Try to change the SSDs' Host Protected Area (HPA) so that only 400 GB of capacity will be visible and then use the "shrunk" SSDs for the pool (as in option #1)?

Or maybe there is no difference at all, and the SSD will automatically make good use of all of its flash cells?

If it matters: I'm assuming that the virtual machine will issue TRIM commands and that they reach the host's ZFS and finally the SSDs themselves.

Background: I'm planning to use ZFS and I need to find the correct ashift parameter for my harddrive, which should be log2(sector_size), e.g. 9 for 512 byte sectors.

My harddrive reports a physical and logical sector size of 512 bytes. I read that some harddrives report wrong information to prevent compatibility problems with operating systems that assume 512 byte sectors. I'm not sure whether that's the case with my harddrive.

So I wrote a small program to help me determine the true physical sector size. The program opens an empty partition on my harddrive and writes blocks of 4096 bytes at 1000 randomly selected locations spread within 1 GiB. The random locations are first aligned to 4096 bytes, then an offset is added. The program performs these 1000 random writes using different offsets and measures how long the writes took for each offset. The first offset is zero, then it is increased in steps of 256 bytes.

When opening the partition for writing, I use the O_WRONLY | O_SYNC | O_DIRECT flags to get as close to the hardware as I can, i.e. circument as many caches as I can. I also make sure that my buffer is properly aligned in memory.

Here's what I would expect:

• For non-zero offsets, the addresses I'm writing to are not aligned to the harddrive's physical sectors (regardless of whether it has 512 or 4096 byte physical sectors). There is at least one sector that has to be modified only partially, so the harddrive has to read that sector, update parts of it and then write it back. That should be the slower case because a read is involved (read-modify-write).
• For zero offset, regardless of whether the harddrive has physical 512 or 4096 byte sectors, the write operations should not require reading any sectors. All sectors affected by the writes should simply be overwritten. This should be the faster case.

But in fact, I cannot notice any difference. The 1000 writes always take around 8.5 seconds. The offset doesn't seem to have any influence:

Offset  Time (ms) for 1000 random writes
------  --------------------------------
0       8459.11
256     8450.69
512     8633.82
768     8533.94
1024    8467.36
1280    8450.63
1536    8525.72
1792    8533.96
2048    8450.64
2304    8450.79
2560    8442.37
2816    8442.38
3072    8442.28
3328    8450.82
3584    8442.27
3840    8450.81

Additional observations/remarks:

• Writing units of 512 bytes results in similar numbers (i.e. no noticeable influence of the offset).
• Just for the case that my partition itself is not aligned to a physical sector boundary, I also tried increasing the offset in 1 byte steps. That way, the "ideal" offset would be found eventually - but still, I couldn't identify any difference.

Can anyone explain this?

For sake of completion, here's my program (in case anyone wants to run it, insert the path to an empty block device into the open call):

#include <chrono>
#include <fcntl.h>
#include <iostream>
#include <random>
#include <unistd.h>

int main()
{
        const int bufferSize = 4096;
        char buffer[bufferSize] __attribute__((aligned(4096)));
        for (int offset = -256; offset < 4096; offset += 256)
        {
                std::mt19937 generator;
                std::uniform_int_distribution<int> distribution(0, 1024 * 1024 * 1024 / 4096);
                if (offset >= 0) std::cout << offset << "\t";
                else std::cout << "Warming up ..." << std::endl;
                int f = open("PATH_TO_EMPTY_BLOCK_DEVICE", O_WRONLY | O_SYNC | O_DIRECT);
                auto t0 = std::chrono::high_resolution_clock::now();
                for (int i = 0; i < 1000; ++i)
                {
                        lseek(f, SEEK_SET, 4096 * distribution(generator) + offset);
                        if (write(f, buffer, bufferSize) != bufferSize) exit(1);
                }
                auto t1 = std::chrono::high_resolution_clock::now();
                close(f);
                if (offset >= 0) std::cout << (1000 * std::chrono::duration_cast<std::chrono::duration<double>>(t1 - t0).count()) << std::endl;
        }

        return 0;
}

I'm running a webserver in a VM.

In order to create consistent backups, I have to stop Apache, MySQL and other processes for a short time before doing a snapshot of the VM's harddrive (LVM-based).

However, there might be some cronjobs currently running on the VM that need access to the MySQL database. I don't want to interrupt them.

Therefore, I'm looking for a way to determine whether there are currently any cronjobs running. When it's time for a backup, I will wait until I don't "disturb" any cronjob.

Any ideas how to accomplish this?