Tag-Archive for » cache «

Sunday, August 04th, 2013 | Author:

History

Much had changed since I last mentioned my personal server – it has grown by leaps and bounds (it now has a 7TB md RAID6) and it had recently been rebuilt with Ubuntu Server.

Arch was never a mistake. Arch Linux had already taught me so much about Linux (and will continue to do so on my other desktop). But Arch definitely requires more time and attention than I would like to spend on a server. Ideally I’d prefer to be able to forget about the server for a while until a reminder email says “um … there’s a couple updates you should look at, buddy.”

Space isn’t free – and neither is space

The opportunity to migrate to Ubuntu was the fact that I had run out of SATA ports, the ports required to connect hard drives to the rest of the computer – that 7TB RAID array uses a lot of ports! I had even given away my very old 200GB hard disk as it took up one of those ports. I also warned the recipient that the disk’s SMART monitoring indicated it was unreliable. As a temporary workaround to the lack of SATA ports, I had even migrated the server’s OS to a set of four USB sticks in an md RAID1. Crazy. I know. I wasn’t too happy about the speed. I decided to go out and buy a new reliable hard drive and a SATA expansion card to go with it.

The server’s primary Arch partition was using about 7GB of disk. A big chunk of that was a swap file, cached data and otherwise miscellaneous or unnecessary files. Overall the actual size of the OS, including the /home folder, was only about 2GB. This prompted me to look into a super-fast SSD drive, thinking perhaps a smaller one might not be so expensive. It turned out that the cheapest non-SSD drive I could find actually cost more than one of these relatively small SSDs. Yay for me. 🙂

Choice? Woah?!

In choosing the OS, I’d already decided it wouldn’t be Arch. Out of all the other popular distributions, I’m most familiar with Ubuntu and CentOS. Fedora was also a possibility – but I hadn’t seriously yet considered it for a server. Ubuntu won the round.

The next decision I had to make didn’t occur to me until Ubiquity (Ubuntu’s installation wizard) asked it of me: How to set up the partitions.

I was new to using SSDs in Linux – I’m well aware of the pitfalls of not using them correctly, mostly due to their risk of poor longevity if misused.

I didn’t want to use a dedicated swap partition. I plan on upgrading the server’s motherboard/CPU/memory not too far in the future. Based on that I decided I will put swap into a swap file on the existing md RAID. The swap won’t be particularly fast but its only purpose will be for that rare occasion when something’s gone wrong and the memory isn’t available.

This then left me to give the root path the full 60GB out of an Intel 330 SSD. I considered separating /home but it just seemed a little pointless, given how little was used in the past. I first set up the partition with LVM – something I’ve recently been doing whenever I set up a Linux box (really, there’s no excuse not to use LVM). When it got to the part where I would configure the filesystem, I clicked the drop-down and instinctively selected ext4. Then I noticed btrfs in the same list. Hang on!!

But a what?

Btrfs (“butter-eff-ess”, “better-eff-ess”, “bee-tree-eff-ess”, or whatever you fancy on the day) is a relatively new filesystem developed in order to bring Linux’ filesystem capabilities back on track with current filesystem tech. The existing King-of-the-Hill filesystem, “ext” (the current version called ext4) is pretty good – but it is limited, stuck in an old paradigm (think of a brand new F22 Raptor vs. an F4 Phantom with a half-jested attempt at an equivalency upgrade) and is unlikely to be able to compete for very long with newer Enterprise filesystems such as Oracle’s ZFS. Btrfs still has a long way to go and is still considered experimental (depending on who you ask and what features you need). Many consider it to be stable for basic use – but nobody is going to make any guarantees. And, of course, everyone is saying to make and test backups!

Mooooooo

The most fundamental difference between ext and btrfs is that btrfs is a “CoW” or “Copy on Write” filesystem. This means that data is never actually deliberately overwritten by the filesystem’s internals. If you write a change to a file, btrfs will write your changes to a new location on physical media and will update the internal pointers to refer to the new location. Btrfs goes a step further in that those internal pointers (referred to as metadata) are also CoW. Older versions of ext would have simply overwritten the data. Ext4 would use a Journal to ensure that corruption won’t occur should the AC plug be yanked out at the most inopportune moment. The journal results in a similar number of steps required to update data. With an SSD, the underlying hardware operates a similar CoW process no matter what filesystem you’re using. This is because SSD drives cannot actually overwrite data – they have to copy the data (with your changes) to a new location and then erase the old block entirely. An optimisation in this area is that an SSD might not even erase the old block but rather simply make a note to erase the block at a later time when things aren’t so busy. The end result is that SSD drives fit very well with a CoW filesystem and don’t perform as well with non-CoW filesystems.

To make matters interesting, CoW in the filesystem easily goes hand in hand with a feature called deduplication. This allows two (or more) identical blocks of data to be stored using only a single copy, saving space. With CoW, if a deduplicated file is modified, the separate twin won’t be affected as the modified file’s data will have been written to a different physical block.

CoW in turn makes snapshotting relatively easy to implement. When a snapshot is made the system merely records the new snapshot as being a duplication of all data and metadata within the volume. With CoW, when changes are made, the snapshot’s data stays intact, and a consistent view of the filesystem’s status at the time the snapshot was made can be maintained.

A new friend

With the above in mind, especially as Ubuntu has made btrfs available as an install-time option, I figured it would be a good time to dive into btrfs and explore a little. 🙂

Part 2 coming soon …

Share
Sunday, April 26th, 2009 | Author:

Trust me. We’re still dealing with regexes – just in a roundabout (and vaguely practical) way. This is a pretty comprehensive listing of how to go about flushing DNS caches while using regexes to show where similar methods deviate.

Why do we want to clear DNS caches exactly?

There are a number of reasons to clear DNS caches, though I believe these are the most common:

  • An intranet service has an private (internal) IP address when on the company network but it has a public IP address for outside access. When you try to access that service from outside after accessing it from inside, there’s a chance that you would have cached the private (inaccessible) IP. A good long-term solution is to make the service inaccessible except via VPN. A simpler solution is to leave work at work. 😛
  • An internet service or web site changes their DNS settings and your desktop/laptop is looking at the “old” setting. In this case, the new setting has not yet propagated. Hosting Admins come across this case very often.
  • Privacy: If someone can track your DNS history then it wouldn’t be too hard to figure out which web sites you’ve been viewing. Though the individual pages you’ve viewed can’t be tracked in this way, the hostnames, such as “dogma.swiftspirit.co.za” or “google.com” will be in the DNS cache, likely in the order you first accessed each site. There are better ways to do this though. One example is to use a Tor network for all DNS requests.

Flushing Windows’ DNS cache, from command prompt:

Evidence suggests that prior to Windows 2000, Windows OS’s didn’t cache DNS results. The ipconfig command, run from the command prompt, was given some control over the DNS cache and has remained roughly the same since.

To get to the prompt if using Vista as non-Admin: Start -> Programs -> Accessories -> Right-click “Command Prompt” -> Run As Administrator

Otherwise: Start -> Run -> [cmd     ] -> [ OK ]

ipconfig /flushdns

Flush the DNS Resolver Cache in Windows

It is also possible to clear the cache in Windows by restarting the “DNS Client” or “Dnscache” service.

Flushing Mac OS X DNS cache, from shell prompt:

Since Mac OS X, Apple Macs have been running a Unix-based, POSIX-compliant, operating system based on Nextstep, itself originally containing code from FreeBSD and NetBSD. Mac OS X uses lookupd or dscacheutil to manage the DNS cache, depending on the version.

To get to the prompt: Applications -> Utilities -> Terminal

(lookupd|dscacheutil) -flushcache

What have we here? As per part 1, the vertical bar indicates that either “lookupd” OR “dscacheutil” are acceptable. The parenthesis indicate that the vertical bar only applies to the “lookupd|dscacheutil” portion of the expression. Thus, the ” -flushcache” is not optional and must be included in the command in order for it to work. Note that these commands produce no output unless there is an error.

Use dscacheutil if you’re using Mac OS X 10.5 (Leopard) or later.

Mac OS X:

lookupd -flushcache

Mac OS X Leopard:

dscacheutil -flushcache

Use dscacheutil to flush the cache in Mac OS X Leopard

There is also a GUI tool, DNS Flusher, which automatically uses the correct command available.

Flushing Linux/Unix’ DNS cache, from shell prompt:

N.B. If you don’t already have either bind (with caching lookup enabled), nscd, or dnsmasq installed and running on your *nix-based desktop/server, you are probably not caching DNS at all and there is nothing to flush. In that case you will be utilising your DNS server for every web request, probably slowing your web experience.* If so, I recommend at least installing nscd as it is the easiest to set up. **

Flushing nscd’s cache

As with the Mac OS command, this produces absolutely no output unless there is an error:

(|sudo )(|/usr/sbin/)nscd -i hosts
  • Use sudo if you’re not already root otherwise the first selection is blank.
  • Specify /usr/sbin/ if nscd is not already within the “path”. If your distribution has nscd in a strange place, locate it first:
locate -r bin/nscd$

Notice that the above “bin/nscd$” is itself a regular expression. 🙂

Using nscd, invalidate the “hosts” cache, logged in as a user:
sudo nscd -i hosts
Using nscd, invalidate the “hosts” cache, logged in as root:
nscd -i hosts
Using nscd, invalidate the “hosts” cache, logged in as root, specifying the full path:
/usr/sbin/nscd -i hosts

Flushing bind’s cache

To flush bind’s cache, we issue a command via rndc. Use sudo if you are not already root:

(|sudo )rndc flush

Restarting the cacheing services also works!

Here’s how to restart either of the caching daemons:

(|sudo )(service |/etc/(rc\.d|rc\.d/init\.d|init\.d)/)(bind|dnsmasq|nscd) restart

That’s starting to get difficult to read. *** Luckily I’ve explained in detail:

  • As with the previous command, use sudo if you’re not already root.
  • The second selection has the first option “service “. This applies mainly to Red Hat/CentOS and Fedora systems.
  • The “/etc/(rc\.d|rc\.d/init\.d|init\.d)/” needs to be expanded further. This is for most other systems. Generally, the rc.d is for if you’re using a BSD-style init system (for example: Arch Linux, FreeBSD, or OpenBSD). The best way to know for sure which command to use is to ‘locate’ the correct nscd or dnsmasq path. Most Unix flavours, even Solaris, use nscd:
locate -r \.d/nscd$ ; locate -r \.d/dnsmasq$ ; locate -r \.d/rndc$
  • The last choice is between “bind”, “nscd”, and “dnsmasq”. This depends entirely on which is installed and in use.
  • The last of the pattern, ” restart”, is the instruction given to the daemon’s control script.

Arch, using dnsmasq, restarting the cache daemon, logged in as root:

/etc/rc.d/dnsmasq restart

Arch, using nscd, restarting the cache daemon, logged in as user:

sudo /etc/rc.d/nscd restart

CentOS / Red Hat, using nscd, restarting the daemon, as root:

service nscd restart

nscdrestart

Flush Mozilla Firefox’s internal DNS cache:

Mozilla Firefox keeps its own DNS cache for performance. Firefox 2 would cache only 20 entries for up to 60 seconds. The default setting as of Firefox 3 appears to be 512 entries for up to 60 minutes which seems much more reasonable for every-day browsing. If your desktop has a built-in cache (which most now do) then the cache here is actually redundant. I’m not aware of any other browsers that implement DNS caching.

I’ve found a few solutions for when you need to clear the cache. It seems there are many ways to do this however these are the easiest, which I’ve put into order of preference.:

  1. Install the Firefox DNS Flusher Addon – provides a button to flush the cache.
  2. Install the DNS Cache Addon – provides a toggle which disables or enables the DNS cache.
  3. Clear Cache (clears browser cache as well as DNS Cache): Select Tools -> Clear Private Data; Deselect all checkboxes except for Cache; Click [ Clear Private Data Now ].
  4. Manually do what DNS Cache does: set the following 2 about:config options “network.dnsCacheExpiration” and “network.dnsCacheEntries” to 0 and then back to the default.

I had a bad cached record and I cleared my browser’s cache. But its still giving me the wrong info. What gives?

Because of how DNS propagation works, you preferably need to flush the DNS on all DNS hosts between yourself and the “authoritive” host, starting with the host closest to the authoritive host (furthest away from your browser).

As an example, if you have a router that is caching DNS, reset the router’s cache before restarting the DNS cache of your operating system, and only then should you clear the cache in Firefox. The reason is that even if you only clear your OS and Firefox’s caches, your desktop is still going to ask the router for its bad record anyway.

What if my DNS server is a server on the net outside my control?

You could try temporarily using a different nameserver, possibly even a publicly open server. OpenDNS shows some good information on how to do this. If you’d like, you should also be able to get relevant information from your own ISP regarding their resolving DNS servers. A local example (South Africa) is SAIX which lists their resolving DNS servers.

* Likely the reason why Firefox has a DNS cache built-in ****
** “((pacman|yaourt) -S|emerge|(yum|aptitude|apt-get) install) nscd” and then ensure that the service is added to the startup scripts. Refer to your distribution’s installation documentation.
*** I’m looking for a syntax highlighting plugin that can work with regex
**** I’ve read statements that restarting the network(ing|) service also clears the DNS cache however I haven’t seen any evidence that this is true. If anyone has a example where this is true, please provide me with the details.
Share