“Files Are Hard” is one of those articles that show how complex even the simplest of things are. How complex is writing to a file? Well, quite. Especially if you want to make sure there’s no corruption in case of a crash. It goes both over the theory and practice, looking at different file systems.
This was only a matter of time … gitfs – version controlled file system:
gitfs was designed to bring the full powers of git to everyone, no matter how little they know about versioning. A user can mount any repository and all the his changes will be automatically converted into commits. gitfs will also expose the history of the branch you’re currently working on by simulating snapshots of every commit.
Here is a brief feature list:
- Automatically commits changes: create, delete, update files and their metadata
- Browse through working index and commit history
- Merges with upstream by automatically accepting local changes
- Caching commits reduces the memory footprint and speeds up navigation
- Reduces the number of pushes by batching commits
πfs – the data-free filesystem!
πfs is a revolutionary new file system that, instead of wasting space storing your data on your hard drive, stores your data in π! You’ll never run out of space again – π holds every file that could possibly exist! They said 100% compression was impossible? You’re looking at it!
Linux Weekly News notifies:
At the June 8 meeting of the Fedora engineering steering committee (FESCo), the group decided that Fedora 16 will ship with Btrfs as its default filesystem. Btrfs is a relatively new copy-on-write filesystem with many interesting features such as read-only and writeable snapshots, multiple device support for RAID, online filesystem defragmentation, and more, though it is still marked as experimental in the kernel. “AGREED: Feature is approved. Will add some base critera to the page to be met by feature freeze. This is just a swap of ext4 to btrfs for default, not change of lvm or other parts of default.“
As noted in the comments, Btrfs is marked as an experimental feature in the kernel. As also noted in the comments, many other features which were marked as experimental were brought into production and that seemed to work fine.
While I personally have no knowledge of Btrfs stability or readiness for production, I am slightly worried by that move. First of all, ext4 – current default filesystem – works fine for me and for everyone I know. Why fixing something that works? It seems that Btrfs is a better choice for server platforms. And while Fedora is mostly used on the desktop, it is still a testing platform for Red Hat distribution which is, in fact, a server-oriented line of products.
On another note, Fedora 15 upgrade was a bumpy ride. Again, not just for me, but for everyone I know. Switch to Gnome3, sysctl, and other changes didn’t quite work out of the box for many people. Btrfs might do the same. I think it’s better to push such a change at least to Fedora 17. Let people recover slightly. Focus instead on fixing things which are broken. Let people regain confidence in Fedora distribution and its upgrade paths. Please.
I came across this blog post which praises text modes for /bin/chmod.
There are two ways you can change file permissions in Unix – one is using
chmod‘s symbolic (text) modes (like
chmod ug+x file), the other is using the octal modes (like
chmod 0660 file). It turns out that symbolic modes are more powerful because you can mask out the permission bits you want to change! Octal permission modes are absolute and can’t be used to change individual bits. Octal modes are also sometimes called absolute because of that.
I have to agree, they are superior. However I feel like the article needs more examples. So here we go.
Use “u” for user, “g” for group, “o” for others, and “a” for all, or you can use a combination of letters, similar to how you do for access rights:
$ chmod ug+rw *.php
This will make all .php files in current directory readable and writable by both user and group.
Use several permission changes within one command. Just separate them by comma.
$ chmod a-rwx,ug+rw,o+r *.php
The above will reset permissions on all .php files to readable by all and writable only by user and group.
And my favorite and most used example, which would be tricky with octal permissions is the “X”. In recursive change mode, “X” will affect executable bit only on directories. Difference by illustration:
$ chmod -R a+x /some/path
The above will add executable bit to all files and folders under /some/path.
$ chmod -R a+X /some/path
But the above will add executable bit only to folders under /some/path. The files will remain as they are.
Here is a productivity tip from the you-don’t-want-to-do-this department:
You don’t want to wait for a filesystem check to finish, when it’s working on a 200 GByte partition.
Hopefully, this tip explains the 5-hour downtime that the server experienced from today’s morning and until now.
As you might know, podcasts are like radio shows recorded and distributed digitally (read: mp3 and RSS). Since pretty much anyone can record a show and distribute it over the Internet – everyone and their brother do that.
The file sizes of some podcasts are huge. There are shows that last for more than an hour and include pieces of music and stereo special effects. I’ve seen this eat up more than 50 MBytes each.
Since I only have a 128 MByte memory card (and about 20 of those MBytes are eaten by software intallations and other data), I was looking at ways to minimize the file sizes of the podcasts that I wanted to listen to.
For a while now I have been using ICQ both at home and at work. Instead of having two different copies of data or running ICQ remotely, I was simply copying all data files over between these two locations.
scp were doing the job just fine. The problem emerged when I started to use ICQ on more than two machines (two machines in the office and one at home). I had to always figure out where is the latest copy of my data and distribute it from there to all the other locations. After doing it manually for just a couple of time bored me to death and I decided to write a script.
I started off with a very specific script that was only meant to copy my ICQ back and forth, but quickly realized that it can be generalized to copy any set of directories. So, here it is – sync_dirs.pl.
This script accepts and requires only one parameter – directory to synchronize. You can define a few shortcuts for frequently used directories inside the script. Locations are also defined inside the script. Since this piece of code uses
Net::SCP, the current limitation is that you must have ssh configured to authorize with keys, not passwords. The good news, is that you need only one location to be able to access all the others. The most recent copy of data will be copied over to this central location and from there distributed to all the other machines.
One thing I liked about Linux is it’s hidden simplicity. When in a hurry, I usually go for the first working solution of a given problem. If the same problem appears often, I can get used to the first solution so much that I don’t even think about simplifying it.
Many beginning Linux users experience difficulties getting used to the filesystem structure. Indeed, there are many files and directories, the structure of which are not as obvious as it could be. Choosing an appropriate location for a new file or directory is difficult and many choose to follow their own instincts.
With more experience, the file hierarchy becomes clearer and old concepts of placing files and directories start to fade out. When it happens, finding things becomes difficult. It is than that users learn that Linux has many tools for finding things. And it is than that they become confused once again.
Read on for a quick introduction into searching tools available in Linux.