linux-kernel - Re: New filesystem for Linux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061104104601.GA16991@wohnheim.fh-wedel.de>
Date:	Sat, 4 Nov 2006 11:46:01 +0100
From:	Jörn Engel <joern@...nheim.fh-wedel.de>
To:	Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: New filesystem for Linux

On Fri, 3 November 2006 20:01:56 +0100, Mikulas Patocka wrote:
> >
> >So which, if I may ask, are the advantages of your design over sprite
> >lfs?
> 
> It is very different from LFS. LFS is log-filesystem, i.e. journal spans 
> the whole device. The problem with this design is that it's fast for write 
> (cool benchmark numbers) and slow in real-world workloads.
> 
> LFS places files according to time they were created, not according to 
> their directory.
> 
> If you have directory with some project where you have files that you 
> edited today, day ago, week ago, month ago etc., then any current 
> filesystem (even ext2) will try to place files near each other --- while 
> LFS will scatter the files over the whole partition according to time they 
> were written. --- I believe that this is the reason why log-structured 
> filesystems are not in wild use --- this is a case where optimizing for 
> benchmark kills real-world performance.

Darn, I was asking the wrong question again.  Let me rephrase:

So which, if I may ask, are the advantages of your crash
count/transaction count design over the sprite lfs checkpoint design?

Allocation strategy is an interesting topic as well.  Rosenblum and
Ousterhout were wrong in their base assumption that read performance
won't matter long-term, as caches are exponentially growing.  It
turned out that storage size was growing just as fast and the ratio
remained roughly the same.  But let us postpone that for a while.

Jörn

-- 
tglx1 thinks that joern should get a (TM) for "Thinking Is Hard"
-- Thomas Gleixner
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/