From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752210AbcKGDrJ (ORCPT <rfc822;w@1wt.eu>);
        Sun, 6 Nov 2016 22:47:09 -0500
Received: from casper.infradead.org ([85.118.1.10]:58678 "EHLO
        casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751469AbcKGDrI (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sun, 6 Nov 2016 22:47:08 -0500
Date: Mon, 7 Nov 2016 03:47:03 +0000 (GMT)
From: James Simmons <jsimmons@infradead.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: devel@driverdev.osuosl.org, Andreas Dilger <andreas.dilger@intel.com>,
        Oleg Drokin <oleg.drokin@intel.com>,
        "John L. Hammond" <john.hammond@intel.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Lustre Development List <lustre-devel@lists.lustre.org>
Subject: Re: [PATCH 22/29] staging: lustre: llite: add LL_IOC_FUTIMES_3
In-Reply-To: <20161030145959.GA31097@kroah.com>
Message-ID: <alpine.LFD.2.20.1611070330280.21293@casper.infradead.org>
References: <1477606323-30325-1-git-send-email-jsimmons@infradead.org> <1477606323-30325-23-git-send-email-jsimmons@infradead.org> <20161030145959.GA31097@kroah.com>
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 
X-CRM114-CacheID: sfid-20161107_034703_832315_D1F46D2E 
X-CRM114-Status: GOOD (  15.97  )
X-Spam-Score: -1.9 (-)
X-Spam-Report: SpamAssassin version 3.4.1 on casper.infradead.org summary:
 Content analysis details:   (-1.9 points, 5.0 required)
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 NO_RELAYS              Informational: message was not relayed via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                             [score: 0.0000]
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Thu, Oct 27, 2016 at 06:11:56PM -0400, James Simmons wrote:
> > From: John L. Hammond <john.hammond@intel.com>
> > 
> > Add a new regular file ioctl LL_IOC_FUTIMES_3 similar to futimes() but
> > which allows setting of all three inode timestamps. Use this ioctl
> > during HSM restore to ensure that the volatile file has the same
> > timestamps as the file to be restored. Strengthen sanity-hsm test_24a
> > to check that archive, release, and restore do not change a file's
> > ctime. Add sanity-hsm test_24e to check that tar will succeed when it
> > encounters a HSM released file.
> 
> This sounds odd, why is this filesystem the only one that needs a
> "special" futimes?  Don't make up new syscalls by making an ioctl
> please, make a new syscall if that's what you really need!

This is a special case dealing with file being retrieve from tape backup.
The file being restored ended up with the wrong timestamps. This ioctl
was used to retrieve the correct timestamps from our meta data servers.
Another difference is that our futimes changes all the timestamps. I see
the main issue is wrapping such functionality into ioctls. We have the
have developed something, ladvise, along the lines of fadvise. We will
have to discuss doing it using syscall instead.