linux-kernel - Re: [0/3] POHMELFS high performance network filesystem. IPv6 support, documentation update.

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] [day] [month] [year] [list]

Message-ID: <20080725203512.GA10873@2ka.mipt.ru>
Date:	Sat, 26 Jul 2008 00:35:13 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Jamie Lokier <jamie@...reable.org>
Cc:	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [0/3] POHMELFS high performance network filesystem. IPv6 support, documentation update.

Hi Jamie.

On Fri, Jul 25, 2008 at 08:40:34PM +0100, Jamie Lokier (jamie@...reable.org) wrote:
> Consider this:
> 
>    1. Client A reads FILE, and registers its interest in FILE.
>          (Contents are not interesting, e.g. 'Hello_sister')
>    2. Client B does "echo Some_message > /mnt/file".
>        - Truncates the file, sending truncate message to server.
>        - "Writing happes during writeback"...?
>    3. Client B sends a message by back-channel to client A (e.g. ssh command).
>    4. Client A reads FILE again.
> 
> Does client A always see 'Some_message' when it reads the file in step 4?
> That's what I'd call coherence.

If 4. happens after writeback of the client B, then it will see the new
content, otherwise it will see empty page. There are no locks (even
implicit like what is expected in POSIX in exactly this case) in
POHMELFS so far.

> For that, the first truncate or write operation on client B must wait
> until a synchronous invalidate request goes to the server, then the
> server sends to all interested clients (A) and waits for a reply, then
> reply to B, and only then can B return from the open()/write() system call.
> 
> And when client A reads the file in step 4, it must send a synchronous
> message to the server which must ask B to write the delayed writeback
> data immediately, and until then, the reply to A will be delayed.
> 
> Is that right?

It _can_ be done that way. But I'm still thinking on how the really
scalable locking (this is a locking mechanism, just implicit) should be
implemented. It is possible to send a message on every write_begin,
which will invalidate appropriate message and every _read_ from that
area will require all writers to flush theirs data. It will be kind of
ME(O)SI cache coherency CPU protocol. It is simple task in current
design, but I'm not yet convinced myself that this is a really scalable
approach. So, there are no locks in POHMELFS _yet_.

-- 
	Evgeniy Polyakov
--
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/