Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp2191878ybm; Sun, 31 May 2020 11:39:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwmMur8PD8AIknda2VbqjfO25jhd/UBxilSeIhZHVlq/0fv08KlrYSWU30so8v6I9bk1MkM X-Received: by 2002:a17:906:35ca:: with SMTP id p10mr15356496ejb.392.1590950366354; Sun, 31 May 2020 11:39:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590950366; cv=none; d=google.com; s=arc-20160816; b=vdPoX2wbF94Vse6kSXZl/99QHR/a1HsArswhLPXiJJckR726bMuVDVusBHDJOBGOHm DRiF/3EB4n+34GlarEzF2GOQG86C9RwOZ1Cui6q9H5zCOry4ei9e1ATdZe5vJtf2ISlV dxoY9pZ+gSTuWSgB4P56QoLfLEMXUYcRnS8rQ/s3Ny3cFrS594q9MtNtYxX50R5VV/Mi N5BLqaXOYxzqSmPqhXPr3MOFvdGNR+sCL8Fpxw2x+UzjUba7uoRvi+pPK/82UaVu7S6n 3kKvSVnix5ucmlN2UAc41bDZhWfiw4Y8oawITxyhQ2r79m9AM5fGDmvCB9z2uqOsakrj Tmuw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=bdBmKyLMgyuSYHluLaPWhpBjUBM5iB5qL+jjoSfvNLc=; b=meWxN6KNzgh83cjj6ryBRSGgnXC47O5d2/tKILWdnC8BxH/zYvckYSPiA588rTeFL9 hVkKTOz0hBTgCnIxXS/he02cPHu2S+GIzrC0TBrrrqfgG7G435TsHyWTTVGarBmaj7V8 QHuroidJQyJ6Eck91IspPrslpXXiaUycc0+k4PePuwppW9ZS8GYIaxEYCumcbPeMysl5 kuSsNGscQofvztbCsnrKnjlEqXVXfRkzZ2YDZgJdkRtKU3764yIBF8T2Rfuhz2mnhzZr pt38ORl+cJkXyZkJJv8Z0O2+D96+a18WX0r2AoekWFo2GtfLVx3TRqT8syh+JmpVILKL oQ5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IFwh45aJ; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l10si9552695edv.152.2020.05.31.11.39.03; Sun, 31 May 2020 11:39:26 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=IFwh45aJ; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728200AbgEaSe4 (ORCPT + 99 others); Sun, 31 May 2020 14:34:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726008AbgEaSez (ORCPT ); Sun, 31 May 2020 14:34:55 -0400 Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8868EC061A0E; Sun, 31 May 2020 11:34:55 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id j10so9244965wrw.8; Sun, 31 May 2020 11:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bdBmKyLMgyuSYHluLaPWhpBjUBM5iB5qL+jjoSfvNLc=; b=IFwh45aJIHiUdXpnhbN2j6fgO4LZZLQuDrlbKE3QlSWYbyfc/fy+sWUop5+ZiKAbPu q71sC8PqSUnLUKaT4iII8Mbw7LCHRZVYblIp1GFzr9ie8eCwnL1RuEDTAxNRCFT+0Hip rfaXbM+9h4Wl5SlBRx1c/AI9b+mL8yszp1wUP0I+jN53od36CQYN9AgjbMF7ManDAsep aVIvuPx4A8JzyKXmVk7d/n4RNnIYqm2fCknUHoEtOBSPmp+LMlANGWiNJhTf45xxRPSf plsNmQjTLjzrVsT1D27OUKvZHKiFQ8BXNfScnmmzlfco0QxM/XrqO8AostdysiB17V8x eOEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bdBmKyLMgyuSYHluLaPWhpBjUBM5iB5qL+jjoSfvNLc=; b=gD8pWttnQg4pIftrPYhYhAE0u1/uOlAKB9DAa3dJEKndgXEfvNwXEPNRpESprG5oPl Hero0z+1iSS1TIM1FGT0X/rzSSWVcMqhCgzkDxycAiVkXz9ntYUm/eFbYGqQBmu/z5o/ UEopBYM1Ehmkcl33o65kKgJLHdbvmthBFdEpykQJM2oWKHNsm9F2YixcOdUVDmeSbUzD /hp+cxxTN1kr0riEoNBN2T59KlaEMl3QTVCH016eHPy9anzWkJPrzpr5ycuN/kx9QXjs WxaQoJB8o96+Kdd+f37xQkQXZIhdJC9VGaUJITquYT2okE7yc2sBcyWsVlbv9b1Lf8DL mxWQ== X-Gm-Message-State: AOAM530gK38AA4s5ej2LOnpRlOrfJ4Xy0gEpWXXIffHI5iBMTpTF9WLw EotfyCZXE9U3c3hMwyWcT7KAJ7d8 X-Received: by 2002:adf:f28f:: with SMTP id k15mr18063086wro.283.1590950066820; Sun, 31 May 2020 11:34:26 -0700 (PDT) Received: from [192.168.0.48] (HSI-KBW-46-223-1-216.hsi.kabel-badenwuerttemberg.de. [46.223.1.216]) by smtp.gmail.com with ESMTPSA id j190sm9297076wmb.33.2020.05.31.11.34.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 May 2020 11:34:26 -0700 (PDT) Subject: Re: [ANNOUNCE] Reiser5: Data Tiering. Burst Buffers. Speedup synchronous modifications To: Pavel Machek Cc: ReiserFS development mailing list , linux-kernel References: <4f919dee-5b72-9269-2bd0-6818a7167864@gmail.com> <20200530101354.GA630@duo.ucw.cz> From: Edward Shishkin Message-ID: Date: Sun, 31 May 2020 20:34:25 +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: <20200530101354.GA630@duo.ucw.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/30/2020 12:13 PM, Pavel Machek wrote: > Hi! > > >> For example, you can use proxy device to store hot data only. With >> such strategy new logical blocks (which are always "cold") will always >> go to the main storage (in contrast with Burst Buffers, where new >> logical blocks first get written to the proxy disk). Once in a while >> you need to scan your volume in order to push colder data out, and >> pull hotter data in the proxy disk. Reiser5 contains a common >> interface for this. It is possible to maintain per-file, or even per- >> blocks-extent "temperature" of data (e.g. as a generation counter), > > Would it be possible to offer userland interface for this? I can > probably say that mp3/video files should be cold, while some source > files should be hot, etc... > > Best regards, > Pavel > Hi Pavel, Yes, it is possible. One just needs to add an ioctl handler for regular files managed by a plugin with STRIPED_FILE_PLUGIN_ID. That handler is to set user-defined "temperature" to a file. Also we'll need an additional on-disk file attribute (32 (or 64?)-bit field in the private part of inode) to store the "temperature" in. It can be added by standard way via implementation of respective stat-data extension in the file reiser4/plugin/item/static_stat.c Finally, we'll need to handle temperature in the common migration procedure balance_volume_asym(), which is responsible for clearing up the proxy device. It should look like this: ... if (!IS_ERR(inode) && inode_file_plugin(inode)->balance && file_is_cold_enough(inode)) { reiser4_iget_complete(inode); /* * migrate data blocks of this file */ ... Currently it works as if all files are "cold" (i.e. migrates everything). Once I find the current stuff more-or-less stable I'll add temperature support and send the patch. Thanks, Edward.