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