This is a tracker bug for QPID-5671. Currently the linearstore uses a default EFP with a file size of 2048k. The following features need to be added to complete this functionality: 1. Change the file structure of the store directory to allow for multiple partitions and EFPs to be used (using links). 2. Add extended queue attributes that allow per-queue selections of both partition and EFP file size. 3. Add a set of tests for this new functionality 4. Provide a utility for the management of partitions and EFPs.
Checkin r.1636598 - This is the first part of resolving this issue and changes the journal directory structure to use symlinks instead of moving the actual files. This opens the way to having files from multiple partitions in the same journal. Other small improvements and tidy-ups also included.
Seel upstream for comments. Release notes are needed for this feature.
Created attachment 986160 [details] Release notes as a txt file
I would like to ask for more operation details. What is the core implemented enhancement? How it should work? and If you have some testing scenario, please provide. Thank you.
The fundamental purpose of linearstore remains unchanged. The default method of using linearstore also remains unchanged. What has been added, however, is the ability to establish Empty File Pools on disk partitions other than the default one (ie the one on which the store directory is by default created). Existing tests of linearstore should not need to be changed to keep working, provided that the EFP was established on the default partition (qls/p001), which is what happens if linearstore creates the EFP on its own. However, it is possible to add some tests to test partition functionality. In particular: * Additional partitions may be mounted or linked to qls/p002, qls/p003, etc., and once this is done, it should be possible to create new queues use these partitions using qpid-config. ** Note that the partitions are NOT created automatically. ** Note also that linearstore reads the qls directory statically at recovery, and thus a partition added while qpidd is running will not be detected and cannot be used until the next restart of qpidd. (This may be improved at a later date so that linearstore can use newly created parttions without the need to restart.) ** Once a pNNN directory is created, an empty "efp" directory must be created under it for linearstore to read it correctly. ** NOTE that the partition being mounted must support O_DIRECT. tempfs, for example does not do this. (see man 2 open for more details on this) ** The number of the partition need not be consecutive, but must be a decimal number > 1 and < 1000 in the form "pNNN" with leading zeros if necessary. * Once established, each partition will behave much the same as the default partition, in which files are taken from the EFP, or if none exists, new files will be crated. Files which are no longer needed in a journal will accumulate in the EFP. * When a queue is created using qpid-config, the partition and EFP file size can be set using "qpid.efp_partition_num" and "qpid.efp_pool_size". Example: -------- Use store dir /qpid-store (make sure qpidd has permissions here) Start broker using --load-module linearstore --store-dir /qpid-store --truncate no --log-enable info+ Stop broker. Run tree /qpid-store, and you should see /qpid-store/qls dir with dat2, jrnl2, and p001 (default partition) dirs. Either link or mount a second partition to /qpid-store/qls/p002. Add empty EFP directory /qpid-store/qls/p002/efp. Restart broker using above params. Look for log message showing empty EFP on partition 2. Run qpid-config to create new queue using this new partition: qpid-config add queue "test_queue" --durable --efp-partition-num 2 --efp-pool-file-size 4096 Stop broker and again run tree /qpid-store, you should see a "4096k" directory under the new partition efp dir, and which contains a single file under "in_use". You should now be able to perform tests on this queue as normal with files being created and pooled in this partition. I hope this gives an idea on how to proceed.
*** Bug 1083986 has been marked as a duplicate of this bug. ***
The current parameters are --efp-partition N and --efp-file-size N. I believe these were simplified a little as the previous ones were a little long and over-bearing. Sorry for the muddle-up. As far as upgrading the store dir, that is something that the customer should do only if there is absolute need. The customer should attempt to close the old broker cleanly and with all messages consumed. If this is not possible, then this procedure will take care of it. Originally the store upgraded automatically, but this created an irreversible change to the store so that if the customer decided to downgrade, they would lose the store. The current layout allows both the old and new stores to co-exist in mutually exclusive locations in the store dir, and provides the ability to back out of an upgrade. Hope that answers your questions.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-1879.html