I had the same question too. If I look at the HDFS implementation as the reference, HDFS setTimes() touches only the directory/file specified. It doesn't do anything else. Therefore it's an O(1) operation.
The Hadoop contract test verifies only that an exception is thrown if the file doesn't exist. On Wed, May 24, 2023 at 1:50 AM Sammi Chen <sammic...@apache.org> wrote: > Hi Wei-Chiu, > > Thanks for working on this. It's good to support an accurate modification > time. > The design document attached in the JIRA HDDS-8278 > <https://issues.apache.org/jira/browse/HDDS-8278> overall looks good. > > I just have one question regarding the directory's modification time > behavior of FSO bucket. If one file gets modified, will its all ancestor > directories' modification time get updated too? > > Thanks, > Sammi > > On Tue, 23 May 2023 at 06:30, Wei-Chiu Chuang <weic...@apache.org> wrote: > > > Hello, > > this proposal is regarding HDDS-8278 > > <https://issues.apache.org/jira/browse/HDDS-8278> implementing Hadoop > > compatible file system setTimes() API. > > > > I'd like to add this API into ofs and o3fs, to support both OBS and FSO > > bucket types. Keys/files/directories are supported. No support for volume > > and buckets. > > > > The use case is HBase. HBase's file cleaner depends on the file > > modification time to work properly. > > > > What to note: HCFS setTimes() updates both modification time and access > > time. In Ozone, we have creation time and modification time, but no > access > > time. IMO this is a wise decision as I've seen access time causing major > > problems with HDFS in the past. So the accessTime parameter in the > > setTimes() API will be ignored by Ozone Manager. > > > > The feature itself is a tiny change: update modificationTime field of an > > OmKeyInfo object. But it requires a huge amount of boilerplate code to > > support this small change. > > > > You can find the link to the PR here: > > https://github.com/apache/ozone/pull/4720 > > > > Thanks, > > Weichiu > > >
