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;
Subject: Re: [ANNOUNCE] Reiser5: Selective File Migration - User Interface
To:     Pavel Machek <pavel@ucw.cz>,
        Metztli Information Technology <jose.r.r@metztli.com>
Cc:     reiserfs-devel@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20200826205216.07BC868EF679@huitzilopochtli.metztli-it.com>
 <20201004095922.GC1104@bug>
From:   Edward Shishkin <edward.shishkin@gmail.com>
Message-ID: <fe9dafa8-0fef-7046-fea7-f2344adc2ee1@gmail.com>
Date:   Sat, 17 Oct 2020 17:53:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20201004095922.GC1104@bug>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 10/04/2020 11:59 AM, Pavel Machek wrote:
> 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?

Hi Pavel,
I guess, admin ones.
With such operation it is possible to organize an attack on a
collectively shared volume by clogging some its brick. So that other
users, who rely on regular distribution (provided by per-volume
distribution table) will get "no space left on device", while other
bricks contain a lot of free space..

> 
>>> 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.
> 

You are right. The current solution is temporary. Actually, we don't
need to lock the whole volume in order to migrate a file (anyway, the
file migration procedure takes an exclusive access to the file).

User-defined migration of individual files should be serialized with
brick removal. So it will be even per-brick lock rather than per-volume
lock.. I think, that it should be a rw-semaphore. Brick removal
procedure will take a write lock (with possible waiting) and
user-defined migration will try to take a read lock. If busy, then
return error (brick is under removal == doesn't exist for user).

Thanks,
Edward.