Seems I've got what you’re talking about. I’ve tried to change the root directory (*persistencePath*) and saw that only data/indexes were placed to it while wal stayed somewhere in my work dir. It works counterintuitive and causes non productive discussions like we are in arguing about *persistencePath* or *storagePath*. Neither name fits this behavior.
My suggestion will be the following: - *persistencePath* refers to the path of all storage files (data/indexes, wal, archive). If the path is changed *all the files* will be under the new directory unless *setWalPath* and *setWalArchivePath* are set *explicitly*. - *setWalPath* overrides the default location of WAL (which is setPersistencePath) - *setWalArchivePath* overrides the default location of the archive (which is again has to be setPersistencePath). If we follow this approach the configuration and behavior becomes vivid. Thoughts? — Denis > On Oct 13, 2017, at 1:21 AM, Ivan Rakov <ivan.glu...@gmail.com> wrote: > > Denis, > > Data/index storage and WAL are located under the same root by default. > However, this is not mandatory: *storagePath* and *walPath* properties can > contain both absolute and relative paths. If paths are absolute, storage and > WAL can reside on different devices, like this: > >> storagePath: /storage1/NMVe_drive/storage >> walPath: /storage2/Big_SSD_drive/wal > We even recommend this in tuning guide: > https://apacheignite.readme.io/docs/durable-memory-tuning > > That's why I think *persistencePath* is misleading. > > Best Regards, > Ivan Rakov > > On 13.10.2017 5:03, Dmitriy Setrakyan wrote: >> On Thu, Oct 12, 2017 at 7:01 PM, Denis Magda <dma...@gridgain.com> wrote: >> >>> From what I see after running an example they are under the same root >>> folder and in different subdirectories. The root folder should be defined >>> by setPersistencePath as I guess. >>> >> If that is the case, then you are right. Then we should not have >> storagePath or WalPath, and store them both under "persistencePath" root. >> However, I would need Alexey Goncharuk or Ivan Rakov to confirm this. >> >
