hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Shvachko (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (HADOOP-1869) access times of HDFS files
Date Thu, 28 Aug 2008 21:09:44 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626680#action_12626680
] 

shv edited comment on HADOOP-1869 at 8/28/08 2:08 PM:
----------------------------------------------------------------------

This is what I get from the discussion above.
- touchAC() method is useful and can find immediate application in fuse.
- for archival and (remote) copy purposes we will need a flag that would create new files
with time (and may be other) attributes having THE SAME value as the source files.
- there is no reasonable use case for setAcessTime method at the moment. I mean nobody needs
to set aTime to yesterday or tomorrow unless it is the time of the file being copied or untared.

In the spirit of _minimizing impact on external APIs_ I propose to 
# introduce {{FileSystem.touchAC()}} and implement it in HDFS as a call to getBlockLocations().
# not introduce setAcessTime() anywhere in hdfs client code including ClientProtocol.

We can always introduce setAcessTime() when it will really be necessary. Because once introduced
its hard to take it back.


      was (Author: shv):
    This is what I get from the discussion above.
- touch() method is useful and can find immediate application in fuse.
- for archival and (remote) copy purposes we will need a flag that would create new files
with time (and may be other) attributes having THE SAME value as the source files.
- there is no reasonable use case for setAcessTime method at the moment. I mean nobody needs
to set aTime to yesterday or tomorrow unless it is the time of the file being copied or untared.

In the spirit of _minimizing impact on external APIs_ I propose to 
# introduce {{FileSystem.touch()}} and implement it in HDFS as a call to getBlockLocations().
# not introduce setAcessTime() anywhere in hdfs client code including ClientProtocol.

We can always introduce setAcessTime() when it will really be necessary. Because once introduced
its hard to take it back.

  
> access times of HDFS files
> --------------------------
>
>                 Key: HADOOP-1869
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1869
>             Project: Hadoop Core
>          Issue Type: New Feature
>          Components: dfs
>            Reporter: dhruba borthakur
>            Assignee: dhruba borthakur
>             Fix For: 0.19.0
>
>         Attachments: accessTime1.patch, accessTime4.patch, accessTime5.patch
>
>
> HDFS should support some type of statistics that allows an administrator to determine
when a file was last accessed. 
> Since HDFS does not have quotas yet, it is likely that users keep on accumulating files
in their home directories without much regard to the amount of space they are occupying. This
causes memory-related problems with the namenode.
> Access times are costly to maintain. AFS does not maintain access times. I thind DCE-DFS
does maintain access times with a coarse granularity.
> One proposal for HDFS would be to implement something like an "access bit". 
> 1. This access-bit is set when a file is accessed. If the access bit is already set,
then this call does not result in a transaction.
> 2. A FileSystem.clearAccessBits() indicates that the access bits of all files need to
be cleared.
> An administrator can effectively use the above mechanism (maybe a daily cron job) to
determine files that are recently used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message