-
Section menu
This document contains only my personal opinions and calls of judgement, and where any comment is made as to the quality of anybody's work, the comment is an opinion, in my judgement.
[file this blog page at: dig del.icio.us Technorati]
Section menu
As previously noted
(1,
2,
3,
4)
IOPS-per-TB
are an important figure of merit
for storage
systems, one that is often underprovided as it gets miscalculated
(often deliberately to reduce the apparent budget for storage
systems below what is necessary).
Target IOPS-per-TB depend on workload and also are a single metric and so it may be desirable to consider also more specific figures-of-merit:
inoderelate mostly to storage maintenance applications as many need to scan lots of metadata, for checking or indexing purposes, at the same time as the user workload runs.
IOPS-per-TB usually are a mix of both, for some given distribution of file sizes.
I have been using Ansible (and several other configuration
managers) for a long time and one annoyance is that setting up and
handling mount
point directories is very
difficult because on typical systems they are not accessible as they
are overlayed by the root
directory of the
filesystem tree mounted on them, and unmounting that filesystem may
not be feasible.
There is a workaround that I have implemented, which is to mount again the filesystem tree containing the mount points with --bind --make-rprivate, and that also is useful in other ways (for example for filesystem tree sweeps):
A private mount does not forward or receive propagation.
[...] Rbind replicates all the mounts in the tree belonging to the specified mount. Rbind mount is bind mount applied to all the mounts in the tree.
There is a peculiarity: this does not work on the actual mount point, it must be applied to a directory which contains the mount point. So if one wants to access the mount point directory /mnt/ regardless of whether a filesystem tree is mounted on it this does not work:
mkdir -p /mnt_ && mount --bind -make-private /mnt_
So in practice since ordinarily all mount points are in the system root filetree it is enough to use that as source, for example somthing with like this:
mkdir -p /.rprivate && mount --bind --make-rprivate / /.rprivate
That remounts the source filesystem without any mounts on the target directory. It is pretty much cost-free so I have put it as permanent in /etc/fstab for the system root directory.
For good quality high-contrast font rendering I uased disabled anti-aliasing and enabled full hinting of well-hinted fonts like those for the the Ubuntu, DejaVu, old Microsoft, typefaces.
However during an upgrade I discovered thata bug in the glyph rendering library meant that disabling anti-aliasing also disabled full hinting, and autohinting seems to work best only with Type 1 fonts, so I got rather ugly glyphs.
I then reasoned that despite the apparent contradiction between full hinting and anti-aliasing, with both full hinting which results in good glyph shapes already anti-aliasing would be in effect minimal and would not result in fuzzy (low contrast, hard to focus on) glyphs and it turned out to be right: I get high contrast glyphs and anti-aliasing occasionally help with a bitof hard to notice fuzzying.
This works particularly well on my 24in 2560x1440 desktop monitor at 120DPI or the 14in 1920x1080 monitor at 160DPI, as then there is very little need for the anti-aliasing to add fuzzying. On 100DPI displays even with full hinting the fuzzying is noticeable, but almost acceptable and much better than anti-aliasing without full hinting. I guess it would be even worse more noticeable on a 75DPI display.
Note: I have been amazed by how much better glyph look on 120DPI displays compared to 100DPI display, and even better of course on 160DPI displays like the 1920×1080 14in display of my laptop.
The bug was apparently fixed in some later library version, but I have decided to keep both full hinting and anti-aliasing enabled, and I am fairly pleased with the look of glyphs.
In FontConfig this is done with:
<match target="font">
<edit binding="normal" mode="append" name="antialias">
<bool>true</bool>
</edit>
</match>
<match target="font">
<edit binding="normal" mode="append" name="hinting">
<bool>true</bool>
</edit>
</match>
<match target="font">
<edit binding="normal" mode="assign" name="hintstyle">
<const>hintslight</const>
</edit>
</match>
Using X resources:
Xft.antialias: true Xft.hinting: true Xft.hintstyle: hintslight
Using X settings:
Xft/Antialias 1 Xft/Hinting 1 Xft/HintStyle "hintslight"
Using DConf:
[org/gnome/desktop/interface] font-antialiasing='grayscale' font-hinting='full' [org/gnome/settings-daemon/plugins/xsettings] antialiasing='grayscale' hinting='full'
Using GNOME settings:
org.gnome.desktop.interface font-antialiasing 'grayscale' org.gnome.desktop.interface font-hinting 'hintslight' org.gnome.settings-daemon.plugins.xsettings antialiasing 'grayscale' org.gnome.settings-daemon.plugins.xsettings hinting 'full'
Note: the hinting style above is set to
hintslight instead of hintfull because the latter
means to use the heavy-duty hints inside a font that in case of
manually hinted fonts often at low DPIs reshape characters
significantly (and in particular fattens their stems) to fit them to
a black-and-white grid, and that is unnecessary if using
antialiasing. Slight hinting is designed for fonts meant for LCD
displays (sometimes called ClearType
fonts).
So on my laptop I have a recent Intel Tiger Lake audio chip ("LP Smart Sound Technology", PCI id 8086:a0c8) with a Realtek ALC236 codec, and I have found that it has been puzzling to get it to work and then correctly, as the mixer seemed to miss some functionality, and I have figured out that:
I have set them appropriately with alsamixer and saved the settring with alsactl store.
Also I have been amazed at the number and size of driver modules for what is a pretty simple sound system:
snd_ctl_led 24576 0 ledtrig_audio 12288 1 snd_ctl_led snd_soc_skl_hda_dsp 24576 0 snd_soc_hdac_hdmi 45056 1 snd_soc_skl_hda_dsp snd_sof_probes 20480 0 snd_soc_intel_hda_dsp_common 16384 1 snd_soc_skl_hda_dsp snd_hda_codec_hdmi 94208 1 snd_hda_codec_realtek 200704 1 snd_hda_codec_generic 122880 1 snd_hda_codec_realtek snd_soc_dmic 12288 1 snd_sof_pci_intel_tgl 12288 0 snd_sof_intel_hda_common 217088 1 snd_sof_pci_intel_tgl soundwire_intel 73728 1 snd_sof_intel_hda_common snd_sof_intel_hda_mlink 45056 2 soundwire_intel,snd_sof_intel_hda_common snd_sof_intel_hda 24576 1 snd_sof_intel_hda_common snd_sof_pci 24576 2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl snd_sof_xtensa_dsp 12288 1 snd_sof_intel_hda_common snd_sof 380928 4 snd_sof_pci,snd_sof_intel_hda_common,snd_sof_probes,snd_sof_intel_hda snd_sof_utils 16384 1 snd_sof snd_soc_hdac_hda 24576 1 snd_sof_intel_hda_common snd_hda_ext_core 36864 5 snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_soc_hdac_hda,snd_sof_intel_hda_mlink,snd_sof_intel_hda snd_soc_acpi_intel_match 102400 2 snd_sof_intel_hda_common,snd_sof_pci_intel_tgl snd_soc_acpi 20480 2 snd_soc_acpi_intel_match,snd_sof_intel_hda_common snd_soc_core 454656 8 soundwire_intel,snd_sof,snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_soc_hdac_hda,snd_sof_probes,snd_soc_dmic,snd_soc_skl_hda_dsp snd_compress 28672 2 snd_soc_core,snd_sof_probes ac97_bus 12288 1 snd_soc_core snd_pcm_dmaengine 16384 1 snd_soc_core snd_hda_intel 61440 0 snd_intel_dspcfg 36864 3 snd_hda_intel,snd_sof,snd_sof_intel_hda_common snd_intel_sdw_acpi 16384 2 snd_sof_intel_hda_common,snd_intel_dspcfg snd_hda_codec 217088 8 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek,snd_soc_intel_hda_dsp_common,snd_soc_hdac_hda,snd_sof_intel_hda,snd_soc_skl_hda_dsp snd_hda_core 151552 11 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_hda_codec_realtek,snd_soc_intel_hda_dsp_common,snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_soc_hdac_hda,snd_sof_intel_hda
