[
https://issues.apache.org/jira/browse/IGNITE-2810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-2810:
---------------------------------------
Assignee: Vladimir Ozerov
> IGFS: Stripe TRASH directory.
> -----------------------------
>
> Key: IGNITE-2810
> URL: https://issues.apache.org/jira/browse/IGNITE-2810
> Project: Ignite
> Issue Type: Task
> Components: IGFS
> Affects Versions: 1.5.0.final
> Reporter: Vladimir Ozerov
> Assignee: Vladimir Ozerov
> Priority: Critical
> Fix For: 1.7
>
>
> *Problem*
> Currently remove operation on IGFS performs soft-delete which essentially
> moves a file/dir to a special hidden "TRASH" directory. Later on, special
> worker inspects this directory and finally removes actual meta and data
> entities.
> As *move* operation requires lock on parent directory, massive removes will
> lead to high contention on TRASH key, yielding poor performance due to no
> parallelization.
> *Solution*
> Let's stripe trash directory. That is, we will create several (e.g. 16) trash
> directories. When entity is to be removed, we will pick random trash and move
> entitty there.
> Delete worker will have to inspect all these directories.
> Note that each node will have to know maximum numbers of trash directories,
> so it knows how to list it with little or no coordination with other nodes.
> To achieve this we can expose "trashCount" property to
> {{FileSystemConfiguration}}. Normally user will not change it. Each node will
> set up a discovery listener which will track new nodes and will know maximum
> amount of trashes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
