From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mx2.suse.de ([195.135.220.15]:53238 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750905AbeCNM4S (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
        Wed, 14 Mar 2018 08:56:18 -0400
Subject: Re: [RFC 4/7] zuf: zuf-rootfs && zuf-core
To: Boaz Harrosh <boazh@netapp.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Cc: Ric Wheeler <rwheeler@redhat.com>,
        Miklos Szeredi <mszeredi@redhat.com>,
        Steve French <smfrench@gmail.com>,
        Steven Whitehouse <swhiteho@redhat.com>,
        Jefff moyer <jmoyer@redhat.com>, Sage Weil <sweil@redhat.com>,
        Jan Kara <jack@suse.cz>, Amir Goldstein <amir73il@gmail.com>,
        Andy Rudof <andy.rudoff@intel.com>,
        Anna Schumaker <Anna.Schumaker@netapp.com>,
        Amit Golander <Amit.Golander@netapp.com>,
        Sagi Manole <sagim@netapp.com>,
        Shachar Sharon <Shachar.Sharon@netapp.com>
References: <d5db55b6-e488-986a-81b1-a3514e8eba81@netapp.com>
 <b5a62d92-eafa-6f11-2370-14812a8a9286@netapp.com>
 <d7a1ee6a-21e1-dc91-6642-d10a4292701a@netapp.com>
From: Nikolay Borisov <nborisov@suse.com>
Message-ID: <55ccf39a-288c-d250-02d9-58fec7a1f471@suse.com>
Date: Wed, 14 Mar 2018 14:56:15 +0200
MIME-Version: 1.0
In-Reply-To: <d7a1ee6a-21e1-dc91-6642-d10a4292701a@netapp.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>



On 13.03.2018 19:36, Boaz Harrosh wrote:
> 
> zuf-core established the communication channels with
> the zus UM Server.
> 
> zuf-root is a psuedo FS that the zus communicates through,
> registers new file-systems. receives new mount requests.
> 
> In this patch we have the bring up of that special FS, and
> the core communication mechanics. Which is the Novelty
> of this code submission.
> 
> The zuf-rootfs (-t zuf) is usually by default mounted on
> /sys/fs/zuf. If an admin wants to run more server applications
> (Note that each server application supports many types of FSs)
> He/she can mount a second instance of -t zuf and point the new
> Server to it.
> 
> (Otherwise a second instance attempting to communicate with a
>  busy zuf will fail)
> 
> TODO: How to trigger a first mount on module_load. Currently
> admin needs to manually "mount -t zuf none /sys/fs/zuf"
> 
> Signed-off-by: Boaz Harrosh <boazh@netapp.com>
<snip>

> +	while (!relay_is_fss_waiting(&zt->relay)) {
> +		mb();
Not something for this early in the development cycle but something to
keep in mind:

Always document all assumptions re. memory barriers usage + intended
pairing scenario otherwise it's very hard to reason whether this is
correct or not. In fact barriers without comments are considered broken.

> +		if (unlikely(!zt->file))
> +			return -EIO;
> +		zuf_dbg_err("[%d] can this be\n", cpu);
> +		/* FIXME: Do something much smarter */
> +		msleep(10);
> +		mb();
> +	}
> +
> +	zt->next_opt = hdr;
> +	zt->pages = pages;
> +	zt->nump = nump;
> +
> +	relay_fss_wakeup_app_wait(&zt->relay, NULL);
> +
> +	return zt->file ? hdr->err : -EIO;
> +}

<snip>