Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id A98CB200CD0 for ; Tue, 25 Jul 2017 20:37:07 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id A7FED1674E2; Tue, 25 Jul 2017 18:37:07 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id ED7861674DE for ; Tue, 25 Jul 2017 20:37:06 +0200 (CEST) Received: (qmail 87533 invoked by uid 500); 25 Jul 2017 18:37:04 -0000 Mailing-List: contact hdfs-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list hdfs-issues@hadoop.apache.org Received: (qmail 87345 invoked by uid 99); 25 Jul 2017 18:37:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Jul 2017 18:37:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 64BB71810CC for ; Tue, 25 Jul 2017 18:37:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id HYBqKdFdlqNP for ; Tue, 25 Jul 2017 18:37:02 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id A38E45FCC7 for ; Tue, 25 Jul 2017 18:37:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id DDD5FE0E08 for ; Tue, 25 Jul 2017 18:37:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 5159A23F36 for ; Tue, 25 Jul 2017 18:37:00 +0000 (UTC) Date: Tue, 25 Jul 2017 18:37:00 +0000 (UTC) From: "Manoj Govindassamy (JIRA)" To: hdfs-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HDFS-12191) Provide option to not capture the accessTime change of a file to snapshot if no other modification has been done MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 25 Jul 2017 18:37:07 -0000 [ https://issues.apache.org/jira/browse/HDFS-12191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100531#comment-16100531 ] Manoj Govindassamy commented on HDFS-12191: ------------------------------------------- [~jingzhao], [~zhz], Nicholas, Would like to understand the rational behind "atime" only or "mtime" only change being part of recordModification(). Technically speaking, it makes sense to record modification for any meta data modification, and since setTime() is changing the meta data, it wants to do record modification. So, would like to know what we would be missing if we are going to skip recoding modification for "atime" changes. > Provide option to not capture the accessTime change of a file to snapshot if no other modification has been done > ---------------------------------------------------------------------------------------------------------------- > > Key: HDFS-12191 > URL: https://issues.apache.org/jira/browse/HDFS-12191 > Project: Hadoop HDFS > Issue Type: Bug > Components: hdfs, namenode > Affects Versions: 3.0.0-beta1 > Reporter: Yongjun Zhang > Assignee: Yongjun Zhang > Attachments: HDFS-12191.001.patch > > > Currently, if the accessTime of a file changed before a snapshot is taken, this accessTime will be captured in the snapshot, even if there is no other modifications made to this file. > Because of this, when we calculate snapshotDiff, more work need to be done for this file, e,g,, metadataEquals method will be called, even if there is no modification is made (thus not recorded to snapshotDiff). This can cause snapshotDiff to slow down quite a lot when there are a lot of files to be examined. > This jira is to provide an option to skip capturing accessTime only change to snapshot. Thus snapshotDiff can be done faster. > When accessTime of a file changed, if there is other modification to the file, the access time will still be captured in snapshot. > Sometimes we want accessTime be captured to snapshot, such that when restoring from the snapshot, we know the accessTime of this snapshot. So this new feature is optional, and is controlled by a config property. > Worth to mention is, how accurately the acessTime is captured is dependent on the following config that has default value of 1 hour, which means new access within an hour of previous access will not be captured. > {code} > public static final String DFS_NAMENODE_ACCESSTIME_PRECISION_KEY = > HdfsClientConfigKeys.DeprecatedKeys.DFS_NAMENODE_ACCESSTIME_PRECISION_KEY; > public static final long DFS_NAMENODE_ACCESSTIME_PRECISION_DEFAULT = 3600000; > {code} > . -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscribe@hadoop.apache.org For additional commands, e-mail: hdfs-issues-help@hadoop.apache.org