[ 
https://issues.apache.org/jira/browse/IGNITE-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15367835#comment-15367835
 ] 

Ivan Veselovsky commented on IGNITE-3343:
-----------------------------------------

We have difficulty there: if accordingly to the current fix plan we don't store 
access/modification time in DUAL modes, we have to write it to the secondary 
file system in response to 
org.apache.ignite.internal.processors.igfs.IgfsImpl#setTimes call. But 
org.apache.ignite.igfs.secondary.IgfsSecondaryFileSystem does not provide a 
method to set access/modification times to a secondary Fs file. So, we either 
should provide such method, or cache the modification/access times in IgfsImpl 
instance in some cases.

> IGFS: Do not query secondary file system properties during 
> create/append/mkdirs.
> --------------------------------------------------------------------------------
>
>                 Key: IGNITE-3343
>                 URL: https://issues.apache.org/jira/browse/IGNITE-3343
>             Project: Ignite
>          Issue Type: Improvement
>          Components: IGFS
>    Affects Versions: 1.6
>            Reporter: Vladimir Ozerov
>            Assignee: Ivan Veselovsky
>            Priority: Critical
>             Fix For: 1.7
>
>
> Currently when we create something in a secondary file system, we perform 
> additional calls to the secondary file system to get file/directory info. 
> This significantly slows down structural operations, while usually it is not 
> really needed in most cases.
> We should do the following:
> 1) Do not write modification time, access time and properties for DUAL 
> entries. Instead, we should propagate "info" and "listFiles" calls to 
> secondary file system right away.
> 2) For {{create()}} we do not need length, as the file is either created from 
> scratch, or truncated.
> 3) For {{append()}} we need to know current length, so the second file system 
> call appears to be inevitable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to