Latest commit 1fe18ba
May 2, 2011
Apparently, FreeBSD is not as forgiving as Linux or OSX when it comes to unaligned reads of block devices. This commit introduces one pread(2) wrapper that does nothing on Linux but on FreeBSD performs aligned reads. That means that for fully unaligned access, there are 3 pread(2) calls instead of the usual 1. Unfortunately, there is some code duplication with op_read.c. But for now let's make this work reasonably on FreeBSD and then let's worry about style. Might be a good idea to get rid of non aligned reads as much as possible, and document the rest (by the use of a different API). Thanks to William Grzybowski for recognizing the problem in the first place.
|Failed to load latest commit information.|
=== ext4fuse === This is a implementation of ext4 for FUSE. A quite limited one, I should say, but still able to mount my ubuntu 10.04 partition. The main reason this exists is to be able to read it from OSX. Of course, this is only readonly, and it should be safe to use. In the worst case scenario you won't be able to mount anything (although I believe that should work). Write support is not going to come for some time: first I should address some design issues, make some tests and get some respectable read performance. If you notice a problem, please fill a bug report, preferably with a logfile attached. You can use the github tracker: * http://github.com/gerard/ext4fuse/issues You can also drop a mail. I'd like to know if someone else is using this besides me. * firstname.lastname@example.org === Usage === Compile using "make". You can mount a filesystem like this: $ ./ext4fuse /dev/disk0s5 mountpoint [optional-logfile] You might need to mount a different device depending on how are your partitions organized. If you don't know, take a look the Mac Disk Utility. At least on Leopard, you need to add your user to the operator group so you can have readonly permissions to the disks. Use this: $ sudo dscl . append /Groups/operator GroupMembership <your-user> === Limitations === * All code is religiously Little Endian only. If you don't know what this means, you are probably OK (ie, you are using x86 or x86-64). * Block numbers over 32 bits aren't supported. You hit those when you reach around the terabyte, and I don't have any way to test that. It should be quite easy to fix, but I don't feel like spending time on something that neither has a use for me or can be proved to be correct. I don't have such big disks :P