Comments on: Lessfs2 development has started

By: naguz

naguz — Thu, 15 Nov 2012 20:56:09 +0000

You might already have answered this in a previous post, but why FUSE? It is frowned upon by many (Linus included, unless he’s misquoted), and thus I tend to think “probably not without reason”. As you probably have had people raise objections to FUSE before, what is you take on it?

By: Filbli

Filbli — Sun, 27 Feb 2011 23:52:59 +0000

I’d like to know about your experience moving from fuse high-level to fuse low-level. Is it just a switch from pathnames to inodes, or is there more involved? I have a read-only fuse filesystem and am considering switching it to fuse low-level, but so far I only have the bare api docs to go by.

By: maru

maru — Sat, 29 Jan 2011 20:03:36 +0000

TC support for storing the actual data has been pulled from 2.x
Both hamsterdb and tc will be used for storing the meta data.

The focus in not on 1.3.x but I will support the 1.x series for some time to come.
At least until 2.x is ready and stable.

I will put a new 2.x development release on sourceforge in a short while.
This new code has a big chunk of the snapshot support code implemented.

By: SR

SR — Sat, 29 Jan 2011 16:32:55 +0000

No I haven’t tried it myself. But I think the performance penalty wont be that bad. Extra reads will occur only when the block with the same hash is found. I think performance is not that important for file system that is used mostly for backup. And this feature is optional.
To gain more performance all check can be performed when there are no other IO operations. For example you write data, check the hashes, see the match with other hashes, write it to journal. When the write is finished you start comparing the data with the same hashes. If there are other IO operations you pause the check and write data and resume check after that. That way the user wont see mush performance loss.

By: wvoice

wvoice — Sat, 29 Jan 2011 16:29:04 +0000

Mark,

I thought TC support was pulled from 2.x. The pre-alpha still seems to require it. Will there be a 2.x release based on hamsterdb soon? Or is all the focus on 1.3.1?

Anything I can do to help keep 2.x moving along?

Thanks,

Mike

By: maru

maru — Wed, 26 Jan 2011 08:03:59 +0000

Yes, this is on the list because more then a few people asked for it. Did you ever try the dedup=verify option with ZFS? What I have learned so far is that the performance penalty is severe. The fact that you can use a lighter hash does not compensate the extra IO.

By: SR

SR — Tue, 25 Jan 2011 23:17:50 +0000

I know that collision probability is very low (I’ve seen the COLLISION.probability file with math). But is it possible to implement something similar to ZFS option dedup=verify in new version? With this option ZFS verifies the blocks byte by byte after the hash match to see if they are really identical.

By: Morten

Morten — Tue, 25 Jan 2011 19:32:38 +0000

Hi Mark

As always, nice work.

Any chance of supporting ACL on lessfs ?

By: cw

cw — Tue, 25 Jan 2011 18:36:35 +0000

gdb says:

Program received signal SIGUSR1, User defined signal 1.
0xb7fe2430 in __kernel_vsyscall ()

By: cw

cw — Tue, 25 Jan 2011 18:17:55 +0000

I set 2 up using the same process as I’ve done for lessfs1 on 2 other systems and I’m in the intit script I’m getting :
$Starting lessfs: User defined signal 1

and in syslog:
lessfs[522]: fopen (null) failed.

all the files seem to be in the right places and the mountpoint exists. Do I need to do something different? how can I make it give a better error?