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]
Date:	Wed, 21 Feb 2007 19:31:40 +0100 (CET)
From:	Juan Piernas Canovas <piernas@...ec.um.es>
To:	Jörn Engel <joern@...ybastard.org>
Cc:	Sorin Faibish <sfaibish@....com>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

Hi Jörn,

On Wed, 21 Feb 2007, [utf-8] Jörn Engel wrote:

> On Wed, 21 February 2007 05:36:22 +0100, Juan Piernas Canovas wrote:
>>>
>>> I don't see how you can guarantee 50% free segments.  Can you explain
>>> that bit?
>> It is quite simple. If 50% of your segments are busy, and the other 50%
>> are free, and the file system needs a new segment, the cleaner starts
>> freeing some of busy ones. If the cleaner is unable to free one segment at
>> least, your file system gets "full" (and it returns a nice ENOSPC error).
>> This solution wastes the half of your storage device, but it is
>> deadlock-free. Obviously, there are better approaches.
>
> Ah, ok.  It is deadlock free, if the maximal height of your tree is 2.
> It is not 100% deadlock free if the height is 3 or more.
>
> Also, I strongly suspect that your tree is higher than 2.  A medium
> sized directory will have data blocks, indirect blocks and the inode
> proper, which gives you a height of 3.  Your inodes need to get accessed
> somehow and unless they have fixed positions like in ext2, you need a
> further tree structure of some sorts, so you're more likely looking at a
> height of 5.
>
> With a height of 5, you would need to keep 80% of you metadata free.
> That is starting to get wasteful.
>
> So I suspect that my proposed alternate cleaner mechanism or the even
> better "hole plugging" mechanism proposed in the paper a few posts above
> would be a better path to follow.

I do not understand. Do you mean that if I have 10 segments, 5 busy and 5 
free, after cleaning I could need 6 segments? How? Where the extra blocks 
come from?

 	Juan.

-- 
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657    Fax: +34968364151
email: piernas@...ec.um.es
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.es&op=index

*** Por favor, envíeme sus documentos en formato texto, HTML, PDF o PostScript :-) ***

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ