rgrunber

Category: Uncategorized

tmpfs all of the things, with anything-sync-daemon

A little while ago, I made a post on profile-sync-daemon. It’s a useful tool for reducing disk I/O with respect to a web browser profile. With that said, there’s other development tools I use as that could benefit from moving the I/O into memory. (eg. default location of local maven repository, $HOME/.m2)

There’s some pretty good documentation and upstream sources , but I don’t think this is packaged in Fedora, and haven’t found an RPM of it anywhere. Luckily it’s actually not that different from profile-sync-daemon, so I was able to use the profile-sync-daemon specfile with some very minor modifications to build it.

To set which directories should be handled by anything-sync-daemon, just modify the /etc/asd.conf file and set the WHATTOSYNC list accordingly . You can parse your config file as well much like profile-sync-daemon to ensure the configuration is correct.

From there, it’s just a matter of starting the service :

$ systemctl start asd.service

In the profile-sync-daemon post I mentioned that it might be nice to put the $HOME/.eclipse under a tmpfs, but this location has fairly predictable file access, and content is rarely written out (mainly during non-RPM/external plugin updates). As a result, this isn’t a great candidate for use with anything-sync-daemon.

One issue that came up was {profile,anything}-sync-daemon’s rsync call attempts to preserve SELinux file contexts (-X) during transfer to/from the tmpfs. SELinux policy will not permit the relabeling but luckily there’s a  nice explanation of this along with some workarounds. I went with changing /usr/bin/rsync from rsync_exec_t to bin_t and the issue seems to have gone away.

No bug left unassigned

There’s something really satisfying about resolving and (especially) closing a ~2.5 year old bug. In this case it wasn’t a new feature or bug, but just better compliance with packaging guidelines regarding bundled libraries. Thanks to all those that helped out!

Zombie Drive

I had a hard disk fail a while ago after about 2 years of use. It wasn’t even being detected as a physical device. It wasn’t that big of a deal as everything was backed up, but I was curious if there was any way to access it once again. I heard a suggestion from a colleague to try freezing the disk in the hopes of getting a last chance to access the data.

Solution : I placed the drive in a ziplock bag, and placed that bag into a larger plastic bag (I couldn’t find another ziplock bag). I left that in the fridge for about 3 hours. I then removed the drive from the bags and reconnected it. The first few times, it failed. Given that it was likely dead, a colleague decided to give it a few bashes (I believe the technical term is ‘kickstarts’). I don’t know if it was the freezing, or just the bashing but the combination allowed me to boot from the disk.

I did not expect that to work.

I tried booting from the drive a few days later, and it also seemed to work. I haven’t connected that drive back in a while, and it may indeed be back to normal but I wouldn’t trust it with anything.