Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2537009pxk; Sun, 4 Oct 2020 03:00:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJydYaFcFO/BDvyjxjiRuMzrlbaM5Pboz/FP1/BzoygbqxS/BDW2DJu2Mgj5e4sVHhj8Fqjw X-Received: by 2002:a17:906:3a0e:: with SMTP id z14mr9863927eje.192.1601805648887; Sun, 04 Oct 2020 03:00:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601805648; cv=none; d=google.com; s=arc-20160816; b=GBv7HvKtU22FilmVsUNc5xLdT88Q2mJQxlu2rA1jj5ScIUinmn2kuUCj34dAz/Y+wp 2SyddfBvF4HLgglh4Y5S7TDW+yeM3L/gUrNnWYcndUwUX/63V6lON76yv6oKH8xNbccH rIl0d2crbx8KAgQSi51pfBCH0KSfIGb6b9DV0vMwIjU5gSEfqo/bsDRdWcKqXHfOPB3n 9IujVrd1FlFDhbVl/s8L7YMYLRIMqU0qrBnxD5F2levdb57MmNXVuKs6XhpvksUKY1s9 C6aq3jp4f2ro0ayLFFfNKsGOdgqNPv712yZC7EoFwEP/RLzzTuFpVkO7J4qwRBhCQcz6 OiAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=gokMLDCnZpdYJdlTS+TVZH/7T/fKUmToTjZQaY4y10I=; b=xqWcuMMU8ljAgqDF/SNEBdCPuD6PG8EF9vEpeOX8XzeT9STVMC9eQyiuzaew7WFJRu gdUGltox/xxf4+oe/m+nmtD1+pVMYijo7LFyjgRSGGJ/G45jY/xYhjGEkToVZ/9pDyzb uMhVfIBOP4RR5+IMRymgTRm8QB9bUsM4sfns2o+Bypt1qBqZh84cUAhMUdQPdaauAVpu wGUs/L/iwfTZoZeg7FcR5884p/Ph3pcvn6kLfdDS4by27VfpsyDgGdhI30wdF/XJqfsJ A8n3DJMJyAxazXIZZXF8WNaTnrhuAjXEHvNvM7eyctFm+9o2GvGhhfSKuGZegdr2/DGE Wo+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id pk27si4939151ejb.715.2020.10.04.03.00.26; Sun, 04 Oct 2020 03:00:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725972AbgJDJ71 convert rfc822-to-8bit (ORCPT + 99 others); Sun, 4 Oct 2020 05:59:27 -0400 Received: from jabberwock.ucw.cz ([46.255.230.98]:49862 "EHLO jabberwock.ucw.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725825AbgJDJ71 (ORCPT ); Sun, 4 Oct 2020 05:59:27 -0400 Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 61A041C0B76; Sun, 4 Oct 2020 11:59:24 +0200 (CEST) Date: Sun, 4 Oct 2020 11:59:23 +0200 From: Pavel Machek To: Metztli Information Technology Cc: edward.shishkin@gmail.com, reiserfs-devel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [ANNOUNCE] Reiser5: Selective File Migration - User Interface Message-ID: <20201004095922.GC1104@bug> References: <20200826205216.07BC868EF679@huitzilopochtli.metztli-it.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <20200826205216.07BC868EF679@huitzilopochtli.metztli-it.com> User-Agent: Mutt/1.5.23 (2014-03-12) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! > > In particular, using this functionality, user is able to push out > > "hot" files on any high-performance device (e.g. proxy device) and pin > > them there. What permissions are normally required for file migration? > > COMMENT. After ioctl successful completion the file is not necessarily > > written to the target device! To make sure of it, call fsync(2) after > > successful ioctl completion, or open the file with O_SYNC flag before > > migration. Ok. > > COMMENT. File migration is a volume operation (like adding, removing a device to/from > > a logical volumes), and all volume operations are serialized. So, any attempt to > > migrate a file, while performing other operation on that volume will fail. If some > > file migration procedure fails (with EBUSY, or other errors), or was interrupted by > > user, then it should be repeated in the current mount session. File migration > > procedures interrupted by system crash, hared reset, etc) should be repeated in the > > next mount sessions. Dunno. Returning -EBUSY is kind of "interesting" there. I'd expect kernel to queue the callers, because userland can't really do that easily. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html