Understanding a national budget can be difficult, with political interests and distorted talking points obscuring the truth. There’s no substitute for diving into the hard data yourself, but it can be difficult to know where to start. [D. Scott Williamson] wanted to do just that, and took an unconventional path – using file system tools to analyse the 2019 US budget.
The basic idea is simple. A file is created for every line item on the budget, and this file is filled with a $ for every million dollars that item costs. These files are sorted into folders for the relevant bureaus and agencies responsible, creating a Fiscal File System representation of the entire budget. The file system can then be analysed with standard tools to get a look at the overall make up of the budget – in this case, WinDirStat does a particularly good job.
It’s a novel way to go about budget analysis, and fills a gap in the market now that Time Plots aren’t producing their Death and Taxes infographics anymore. Pre-cooked file systems covering budgets back to 1977 are available for your perusal, should you need to investigate how things have changed over time.
Unsurprisingly, we haven’t covered the national budget before, but we’re always down to talk file systems.
Whether you’re at the hobbyist level or a professional, if you’re working on code for operating systems or file systems, tools can make or break the job. [Ben Lunt] is an enthusiast hacker himself, and found that over time, a series of useful utilities had proliferated beyond reasonable management. It was time to solve the problem – enter ULTIMATE.
ULTIMATE is a combination of a wide swathe of file system hacking tools that [Ben] had developed over the preceding years. Capable of dealing with most FAT variants, Ext4, ISO, [Ben]’s own FYS FS as well as other Linux ephemera, it enables a wide variety of common tasks to be executed from within a single program.
Capabilities of the tool are wide ranging. Files can be inserted into and removed from image files, boot records can be altered, and there’s even the ability to tinker with GPTs for UEFI-based systems. [Ben] has also experimented with the concept of the eMBR – an extended Master Boot Record with greater functionality for larger, modern hard drives.
ULTIMATE is a testament to [Ben]’s broad file system knowledge, and could likely serve useful to many hackers in the file system and OS community. Just be cautious, though – the software is still in an early stage of development. If you’re just getting started in this particular realm of tinkering, take our primer on file system forensics.
The old saying is if your data isn’t backed up at least twice, it’s not backed up at all. For those not wise enough to heed this adage, there are a number of options available to you if you wish your data to be recovered. Assuming the drive itself is just corrupted somehow (maybe a malicious attack, maybe a user error) and not damaged beyond physical repair, the first step is to connect the drive to another computer. If that fails, it might be time to break out the computer forensics skills.
[Luis]’s guide is focused on Linux-specific drives and recovery tools, so this isn’t necessarily a general-purpose how-to. That being said, there is a lot of information in this guide such as how to mount the target drive’s partitions, how to set up various timelines, and which of the Linux system’s logs are important for the forensic analysis. This specific example in the guide also goes into detail about noticing which of the recent files had been accessed, what they might have done, and different approaches to piecing the mystery of this corrupted drive together.
[Luis] points out that the world of Linux forensics is much different from that of Windows, but for anyone looking to get started he suggests starting with a clean Linux install and going from there. There are many other avenues of digital forensics, as well; the field has as many avenues of exploration as there are different types of computers.
Usually, you think of solid state storage as faster than a rotating hard drive. However, in the case of the Raspberry Pi, the solid state “disk drive” is a memory card that uses a serial interface. So while a 7200 RPM SATA drive might get speeds in excess of 100MB/s, the Pi’s performance is significantly less.
[Rusher] uses the Gluster distributed file system and Docker on his Raspberry Pi. He measured write performance to be a sluggish 1MB/s (and the root file system was clocking in at just over 40MB/s).
There are an endless number of settings you could tweak, but [Rusher] heuristically picked a few he thought would have an impact. After some experimentation, he managed 5MB/s on Gluster and increased the normal file system to 46 MB/s.
Continue reading “Improving Raspberry Pi Disk Performance”
An SD card is surely not an enterprise grade storage solution, but single board computers also aren’t just toys anymore. You find them in applications far beyond the educational purpose they have emerged from, and the line between non-critical and critical applications keeps getting blurred.
Laundry notification hacks and arcade machines fail without causing harm. But how about electronic access control, or an automatic pet feeder? Would you rely on the data integrity of a plain micro SD card stuffed into a single board computer to keep your pet fed when you’re on vacation and you back in afterward? After all, SD card corruption is a well-discussed topic in the Raspberry Pi community. What can we do to keep our favorite single board computers from failing at random, and is there a better solution to the problem of storage than a stack of SD cards?
Continue reading “Single Board Revolution: Preventing Flash Memory Corruption”
[Andrew Smallbone] wrote in with a link to his latest open source project. This is phatIO, a USB I/O device that uses a mass storage file system for control. The idea is that any operating system can manipulate files on a USB storage device. This enumerates as mass storage, and any alterations you make to its file system will result in pin manipulation on the I/O header.
We’ve long been Linux advocates and enjoy the fact that everything on a *nix system is a file. This simply extends the idea across multiple platforms. [Andrew’s] guide for the hardware gives an overview of how the system is structured. The top ‘io’ directory contains sub-directories called mode, pins, status, and a few others. Inside the directories are files for each pin. Writing to these files has much the same effect as writing to a data direction register, port register, or reading a pin register on a microcontroller.
The board is not yet in production and the github link to his hardware files gives us a 404 error. But there is code available for several software demos. After the break we’ve included video of the phatIO driving a Larson scanner.
Continue reading “phatIO uses file system to control external hardware”