FUSE driver for the LEAN file system 0.7

[mid]

I've gotten interested in the LEAN file system for it's high elegance. The available driver, while it does it's job, I hadn't been fully satisfied with. Being a sucker for uniformity, I ended up making a FUSE driver instead. It seems to be able to write, read, create, delete files with little issues. It can also create a new volume. Most corruption bugs I'd been able to find & reproduce are solved. Here's an example of its usage, with the demo image available on fysnet:

Code: Select all

$ #The 0x4600 is the offset of the volume in the image
$ ./leanfuse -O0x4600 mnt fysos64.img
$ tree -hDp mnt
mnt
├── [---------- 3.1K Apr  6 05:39]  bsod.sys
├── [d---------   48 Apr  6 05:39]  EFI
│   └── [d---------  128 Apr  6 05:39]  BOOT
│       ├── [----------  31K Apr  6 05:39]  BOOTIA32.EFI
│       ├── [----------  38K Apr  6 05:39]  BOOTx64.EFI
│       └── [----------  185 Apr  6 05:39]  STARTUP.NSH
├── [---------- 507K Apr  6 05:39]  kernel32.sys
├── [---------- 637K Apr 23 07:10]  kernel64.sys
├── [----------  92K Apr  6 05:39]  loader.sys
├── [d---------   80 Apr  6 05:39]  system
│   ├── [d---------  512 Apr  6 05:39]  fonts
│   │   ├── [---------- 1.6K Apr  6 05:39]  arial.fnt
│   │   ├── [---------- 1.8K Apr  6 05:39]  couriernew.fnt
│   │   ├── [---------- 3.6K Apr  6 05:39]  ImprintShadow.fnt
│   │   ├── [---------- 3.2K Apr  6 05:39]  lucidac.fnt
│   │   ├── [---------- 4.9K Apr  6 05:39]  OCRAExtended.fnt
│   │   ├── [---------- 4.7K Apr  6 05:39]  sansserf.fnt
│   │   ├── [---------- 1.7K Apr  6 05:39]  Simple.fnt
│   │   ├── [---------- 5.1K Apr  6 05:39]  sys8x12.fnt
│   │   ├── [---------- 5.6K Apr  6 05:39]  sys8x14.fnt
│   │   ├── [---------- 6.1K Apr  6 05:39]  sys8x16.fnt
│   │   ├── [---------- 4.1K Apr  6 05:39]  sys8x8.fnt
│   │   ├── [---------- 6.6K Apr  6 05:39]  sys9x16.fnt
│   │   ├── [---------- 2.8K Apr  6 05:39]  System128.fnt
│   │   ├── [---------- 5.6K Apr  6 05:39]  System256.fnt
│   │   └── [---------- 1.7K Apr  6 05:39]  wopr.fnt
│   └── [d---------  224 Apr  6 05:39]  grfx
│       ├── [---------- 134K Apr  6 05:39]  hallway.gif
│       ├── [---------- 169K Apr  6 05:39]  images.sys
│       ├── [---------- 472K Apr  6 05:39]  snow.bmp
│       ├── [---------- 527K Apr  6 05:39]  tron6.tga
│       ├── [---------- 780K Apr  6 05:39]  tron.png
│       └── [---------- 1.6M Apr  6 05:39]  TronUprising.png
└── [----------  16K Apr  6 05:39]  system.sys

5 directories, 29 files
$ identify mnt/system/grfx/hallway.gif 
mnt/system/grfx/hallway.gif GIF 640x480 640x480+0+0 8-bit sRGB 256c 136775B 0.000u 0:00.000
$ echo "Test" > mnt/test
$ ls mnt
bsod.sys  EFI  kernel32.sys  kernel64.sys  loader.sys  system  system.sys  test
$ cat mnt/test
Test
$ rm mnt/test
$ ls mnt
bsod.sys  EFI  kernel32.sys  kernel64.sys  loader.sys  system  system.sys
$ umount mnt
$

Some features are yet to be implemented, such as a defragger, indirect block addressing; the times are also slightly incorrect because of leap seconds, the implementation is pretty icky in regards to quality and speed, but this has prepared me for writing a "real" LEAN driver, and it'll let me prepare an OS image containing a LEAN filesystem automatically. I'd also like to say, opening those images in an image viewer felt like cracking open a treasure chest :).

The source is available on the repository here. Building is as simple as `make`, while having a cc and libfuse installed.

Due to stupidities in some text editor implementations, they may not work with writing files in the filesystem. One text editor, who asked to be anonymous, creates a temporary file and then replaces it with the real file upon saving. Because the rename operation isn't implemented in leanfuse, you can't edit files at all in it.

[nullplan]

the times are also slightly incorrect because of leap seconds,

I don't quite understand, does LEAN mandate the times be in TAI? Because that is the only way how leap seconds will have any bearing at all on the code. And of course leap seconds are a bit of a problem, mainly because you can't predict them. You can only keep a list of them and keep it up to date.

Due to stupidities in some text editor implementations, they may not work with writing files in the filesystem. One text editor, who asked to be anonymous, creates a temporary file and then replaces it with the real file upon saving. Because the rename operation isn't implemented in leanfuse, you can't edit files at all in it.

Well, that is the standard way for writing files in UNIX. This way, you do not have to create a fancy way to prevent the consumer from reading the file when you are not done yet (and also the process could fail at any time, still), but rather, as soon as the correct name appears, the file can be read and will contain the correct stuff. The problem here is just that you did not implement rename().

[nexos]

Because the rename operation isn't implemented in leanfuse, you can't edit files at all in it.

How come you didn't implement rename?

[mid]

I don't quite understand, does LEAN mandate the times be in TAI? Because that is the only way how leap seconds will have any bearing at all on the code. And of course leap seconds are a bit of a problem, mainly because you can't predict them. You can only keep a list of them and keep it up to date.

I'll admit I haven't done too much research on this since it wasn't a priority, but FUSE receives times which include leap seconds, while LEAN stores times excluding leap seconds, so there should be some inconsistency adding up over time.

Well, that is the standard way for writing files in UNIX. This way, you do not have to create a fancy way to prevent the consumer from reading the file when you are not done yet (and also the process could fail at any time, still), but rather, as soon as the correct name appears, the file can be read and will contain the correct stuff. The problem here is just that you did not implement rename().

I see, but I don't find it any less ugly of a solution, if we're talking ideals.

How come you didn't implement rename?

I just hadn't the need yet. My only use for this as of now is to generate volumes in advance that my OS would read later, so the most I needed is the ability to copy files to it. The rename operation in FUSE also intimidated me a bit, but it's not scary in retrospect, so I'll add it shortly.

[iansjack]

Well, that is the standard way for writing files in UNIX. This way, you do not have to create a fancy way to prevent the consumer from reading the file when you are not done yet (and also the process could fail at any time, still), but rather, as soon as the correct name appears, the file can be read and will contain the correct stuff. The problem here is just that you did not implement rename().

I see, but I don't find it any less ugly of a solution, if we're talking ideals.

What mechanism would you propose as the ideal to solve this problem? In particular, corruption of the file being updated.

[BenLunt]

the times are also slightly incorrect because of leap seconds,

I don't quite understand, does LEAN mandate the times be in TAI? Because that is the only way how leap seconds will have any bearing at all on the code. And of course leap seconds are a bit of a problem, mainly because you can't predict them. You can only keep a list of them and keep it up to date.

Hi guys,

I am glad for your interest in LEAN.

As for the time stamps, the LEAN specification states:

This field is computed as the signed number of microseconds since 1970-01-01 00:00:00.000000 UTC, not including leap seconds.

As stated, to include leap seconds, a list of a count of leap seconds would have to be included. Also, you may notice that the time stamps in the demo file you mention are only accurate to the second, not microsecond. This is due to the host system using a Second Time Stamp, then multiplying by 1,000,000 to get microseconds.

As for TAI, I am guessing you were referring to "International Atomic Time". Is this correct?

Anyway, I am not familiar with FUSE nor very familiar with Linux time stamps. Can you specify to Linux/FUSE to ignore leap seconds when calculating a time stamp?

Thank you,
Ben

[nullplan]

As for TAI, I am guessing you were referring to "International Atomic Time". Is this correct?

It is. So LEAN is indeed mandating UNIX time in UTC, and not TAI. Since most operating systems also do not use TAI but UTC, that means there is absolutely no issue with leap seconds.

Anyway, I am not familiar with FUSE nor very familiar with Linux time stamps. Can you specify to Linux/FUSE to ignore leap seconds when calculating a time stamp?

Linux maintains the internal time in UTC. All userspace applications I have seen, including all libcs I have looked at, require the time be kept in UTC. Now, theoretically Linux could be made to have its timestamp in TAI, but that would mean that when converting from system time to calendar date and clock time, you first have to apply the TAI->UTC correction, and you would have to do that in userspace. And nobody wants that. UTC->local time zone is enough of a hassle as it is.