• PFC subject chosen

    A while ago, I was doubtful about the subject of my undergraduate thesis (or PFC as we call it). At first, I wanted to work on a regression testing framework for NetBSD. This is something I really want to see done and I'd work on it if I had enough free time now... Unfortunately, it didn't fit quite well my expectations for the PFC: it was a project not related at all with the current research subjects in my faculty, hence it was not appropriate enough to integrate into one of these work groups.So, after inverstigating some of the projects proposed by these research groups, I've finally settled on one that revolves around heterogeneous multiprocessor systems such as the Cell Broadband Engine. The resulting code will be based on Linux as it is the main (only?) platform for Cell development, but the concepts should still be applicable to other systems. Who knows, maybe I'll end up trying to port NetBSD to a Cell machine — shouldn't be too hard if that G5 support is integrated ;-)The preliminary title: Efficient resource management in heterogeneous multiprocessor systems. For more details, check out the Project proposal (still not concreted, as you can see). [Continue reading]

  • Mac OS X aliases and symbolic links

    Even though aliases and symbolic links may seem to be the same thing in Mac OS X, this is not completely true. One could think they are effectively the same because, with the switch to a Unix base in version 10.0, symbolic links became a "normal thing" in the system. However, for better or worse, differences still remain; let's see them.Symbolic links can only be created from the command line by using the ln(1) utility. Once created, the Finder will represent them as aliases (with a little arrow in their icon's lower-left corner) and treat them as such. A symbolic link is stored on disk as a non-empty file which contains the full or relative path to the file it points to; then, the link's inode is marked as special by activating its symbolic link flag. (This is how things work in UFS; I suspect HFS+ is similar, but cannot confirm it.)Aliases, on the other hand, are created from the Finder (and possibly with SetFile(1), but I don't know how) and are stored as regular, empty files if inspected from the command line. However, they have the a extended attribute set on them, which marks them as special files, and the necessary information is stored (I think) in their resource fork.The interesting thing about aliases is that they are more versatile than symbolic links. For example: an alias can point to a file that is stored inside a disk image. When accessing such an alias, the system will automatically mount the corresponding disk image if not already mounted and then redirect you to the file. This may be interesting to transparently access files saved into an encrypted disk image: you store the files into the image, create aliases to them on your desktop and, when opened by any alias-aware application, the system will ask you for the image's password, mount it and provide you the file. But, unfortunately, aliases do not work from the command line, so this benefit is not as impressive as it could be (at least for me). [Continue reading]

  • Hide a volume in Mac OS X

    Yesterday, we saw how to install Mac OS X over multiple volumes, but there is a minor glitch in doing so: all "extra" volumes will appear as different drives in the Finder, which means additional icons on the desktop and its windows' sidebars. I find these items useless: why should I care about a part of the file system being stored in a different partition? (Note that this has nothing to do with icons for removable media and external drives, a these really are useful.)The removal of the extra volumes from the sidebars is trivial: just right-click (or Control+click) on the drive entry and select the Remove from Sidebar option.But how to deal with the icons on the desktop? One possibility is to open the Finder's preferences and tell it to not show entries for hard disks. The downside is that all direct accesses to the file system will disappear, including those that represent external disks.A slightly better solution is to mark the volume's mount point as hidden, which will effectively make it invisible to the Finder. To do this you have to set the invisible extended attribute on the folder by using the SetFile(1) utility (stored in /Developer/Tools, thus included in Xcode). For example, to hide our example /Users mount point:# /Developer/Tools/SetFile -a V /UsersYou'll need to relaunch the Finder for the changes to take effect.The above is not perfect, though: the mount point will be hidden from all Finder windows, not only from the desktop. I don't know if there is any better way to achieve this, but this one does the trick... [Continue reading]

  • Install Mac OS X over multiple volumes

    As you may already know, Mac OS X is a Unix-like system based on BSD and Mach. Among other things, this means that there is a single virtual file system on which you can attach new volumes by means of mount points and the mount(8) utility. One could consider partitioning a disk to place specific system areas in different partitions to prevent the degradation of each file system, but the installer does not let you do this (I suspect the one for Mac OS X Server might have this feature, but this is just a guess). Being Unix, this doesn't mean it isn't possible!As a demonstration, I explain here how to install Mac OS X so that the system files are placed in one partition and the users' home directories are in another one. This setup keeps mostly-static system data self contained in a specific area of the disk and allows you to do a clean system reinstall without losing your data nor settings.First of all boot the installation from the first DVD and execute the Disk Utility from the Utilities menu. There you can partition your disk as you want, so create a partition for the system and one for the users; let's call them System and Users respectively, being on the disk0s2 and disk0s3 devices. Both should be HFS+, but you can choose whether you want journaling and/or case sensitivity independently. Exit the tool and go back to the installer.Now do a regular install on the System volume, ignoring the existence of Users. To make things simple, go through the whole installation, including the welcome wizard. Once you are in the default desktop, get ready for the tricky stuff.Reboot your machine and enter single user mode by pressing and holding Command+s just after the initial chime sound. At the command line, follow the instructions to remount the root volume as read/write. If I recall correctly, it tells you to do:# fsck -fy /# mount -u rw /Mount the Users volume in a temporary location, copy the current contents of /Users into it and remove the original files. For example:# mkdir /Users2# mount -t hfs /dev/disk0s3 /Users2# rsync -avE /Users/ /Users2... ensure that /Users2 matches /Users ...# rm -rf /Users/.[a-zA-Z_]* /Users/*# umount /Users2# rmdir /Users2I used rsync(1) instead of cp(1) because it preserves the files' resource forks, if present (provided you give it the -E option).Once the data migration is done, you can proceed to tell the system to mount the Users volume in the appropriate place on the next boot. Create the /etc/fstab file and add the following line to it:/dev/disk0s3 /Users hfs rwEnsure it works by mounting it by hand:# mount /UsersIf no problems arise, you're done! Reboot and enjoy your new system.The only problem with the above strategy is that your root volume must be big enough to hold the whole installation before you can reorganize the partitions. I haven't tried it but maybe, just maybe, you could do some manual mounts from within the Terminal available in the installer. That way you'd set up the desired mount layout before any files are copied, delivering the appropriate results. Note that if this worked, you'd still need to do the fstab trick in this case, but you'd have to do it on the very first reboot, even before the install is complete! [Continue reading]

  • MacBook Pro review

    Since the Intel Macs were published, I had been planning to get one of them; I settled on getting an iMac 20" by next Summer (so that it'd carry Leopard "for free"). But last December I found a great offer on the MacBook Pro 15.4", being the total price similar to what I was planning to buy. Furthemore, going for the MacBook Pro instead of the iMac let me get rid of my iBook G4 and my desktop PC.Now it has been a little over two weeks since I received the MacBook Pro 15.4", equiped with a Core 2 Duo at 2.16GHz and the 2 GB of RAM, 160 GB hard disk updates. It has been enough time to get a decent impression of the machine, so let me post a little review.The laptop is great overall. It is fast, full of features and tiny details, and has an excelent look (highly subjective ;-). Compared to the iBook G4, which had a 12" 4:3 screen, this one is noticeable bigger (15.4" 16:10) but is thinner and weights almost the same. Sincerely I don't care too much because it was also replacing the desktop PC I had, so I really wanted to have a large resolution to work comfortably (plus a decent video card, only available in the Pro model).As regards performance, the Core 2 Duo is certainly faster than the processors in the other machines. For example, the old PC needed between 5 to 6 hours to build a full NetBSD release, while the C2D takes less than 2 (1.45, if I recall correctly). Games also behave appropriately, even at the highest available resolution (1400x900). Unfortunately, the hard disk (which does 5400RPM "only") is a bottleneck for my typical development (or gaming) tasks, as I outlined in a previous post.Somewhat related to the previous post, the hardware virtualization available in these new microprocessors is awesome. Anyone who deals with cross-development should consider getting one of them: it's impressive to see two (or more!) different operating systems working at the same time at native speeds.Aside that, the machine is full of tiny details. You probably know most of them: the MagSafe connector, the keyboard's backlight, the integrated webcam and microphone or the Apple Remote. I kinda like this last item, although it does not shine as it could if it was in an iMac.However it has its problems too. When the fans spin up, it becomes very noisy... and this happens as soon as you start building any piece of software or launch a game. On another order of things, I've been attempting to install Windows XP on a partition that is not at the end of the disk and haven't been successful, which means it is restricted to the slower part of the drive (a pity for games, specially). But well, not that I can blame Apple because Boot Camp is still beta.Not much more I can say. These machines have been reviewed in depth all around already.And to conclude, a shot of my current desktop :-) [Continue reading]

  • CVS and fragmentation

    First of all, happy new year to everybody!I've recently got a MacBook Pro and, while this little machine is great overall, the 5400 RPM hard disk is a noticeable performance bottleneck. Many people I've talked to say that the difference from 5400 to 7200 RPM should not be noticeable because:These 2.5-inch drives use perpendicular recording, hence storing data with a higher bit density. This means that, theorically, they can read/write data more quickly achieving speeds similar to 7200 RPM drives.Modern file systems prevent fragmentation, as described here for HFS+.To me, these two reasons are valid as long as you manage large files: the file system will try to keep them physically close and the disk will be able to transfer sequential data fairly quickly.But unfortunately, these ideas break when you have to deal with thousands of tiny files around (or when you flood the drive with requests from different applications, but this is not what I want to talk about today). The easiest way to demonstrate this is to use CVS to manage a copy of pkgsrc on such drives.Let's start by checking out a fresh copy of pkgsrc from the CVS repository. As long as the file system has a lot of free space (and has not been "polluted" by erased files), this will run quite fast because it will store all new files physically close (theorically in consecutive cylinders). Hence, we take advantage of the higher bit densities and the file system's file allocation policy. Just after the check out operation (or unarchiving of a tarball of the tree), run an update (cvs -z3 -q update -dP) and write down the amount of time it takes. In my specific tests, the update took around 5 minutes, which is a good measure; in fact, it is almost the same I got in my desktop machine with a 7200 RPM disk.Now start using pkgsrc by building a "big" package; I've been doing tests with mencoder, which has a bunch of dependencies and boost, which installs a ton of files. The object files generated during the builds, as well as the resulting files, will be physically stored "after" pkgsrc. It is likely that there will be "holes" in the disk because you'll be removing the work directories but not the installed files, which will result in a lot of files stored non-contiguously. To make things worse, keep using your machine for a couple of days.Then, do another update of the whole tree. In my specific tests, the process now takes around 10 minutes. Yes, it has doubled the original measure. This problem was also present with faster disks, but not as noticeable. But do we have to blame the drive for such a slowdown or maybe, just maybe, it is CVS's fault?The pkgsrc repository contains lots of empty directories that were once populated. However, CVS does not handle such entries very well. During an update, CVS recreates these empty directories locally and, at the end of the process, it erases them provided that you passed the -P (prune) option. Furthermore, every such directory will end up consuming, at least, 5 inodes on the local disk because it will contain a CVS control directory (which typically stores 3 tiny files). This continuous creation and deletion of directories and files fragment the original tree by spreading the updated files all around.Sincerely, I don't know why CVS works like this (anyone?), but I bet that switching to a superior VCS could mitigate this problem. A temporary solution can be the usage of disk images, holding each source tree individually and keeping its total size as tight as possible. This way one can expect the image to be permanently stored in a contiguous disk area.Oh, and by the way: Boot Camp really suffers from the slow drive because it creates the Windows partition at the end of the disk; that is, its inner part, which typically has slower access times. (Well, I'm not sure if it'd make any difference if the partition was created at the beginning.) Launching a game such as Half-Life 2 takes forever; fortunately, when it is up it is fast enough.Update (January 9th): As "r." kindly points out, the slower part of the disk is the inner one, not the outer one as I had previously written (had a lapsus because CDs are written the other way around). And the reason is this: current disks use Zone Bit Recording (ZBR), a technique that fits a different amount of sectors depeding on the track's length. Hence, outer (longer) tracks have more sectors allocated to them and can transfer more data in a single disk rotation. [Continue reading]