Proxy Device Administration
Proxy device of a logical volume is a brick, which doesn't participate in regular data distribution, but has a priority when allocating addresses for data stripes. In other words, any new data will get first to the proxy device. All data on the proxy device is a subject of flushing by any user-defined strategy (LFU, LRU, ARC, FIFO, MRU, etc).
Proxy bricks are supported by reiser5 (reiser4 experimental format 5.1.3). See Logical Volumes stuff for more details.
Adding a proxy device to a logical volume
At any time you are able to add a proxy device to your logical volume. Currently only one proxy device per logical volume is supported. Also there a restriction that the volume shouldn't be marked as a "volume with incomplete removal". Also any device, which participates in regular data distribution can not be a proxy device.
After adding proxy device to logical volume, capacity of the last one gets increased precisely on the capacity of that device.
Operation of adding a proxy device will automatically turn on specified tiering policy. Currently there is a single one - Burst Buffers. Thus, once being added to a logical volume, proxy device gets an absolute priority in block allocations (including journal blocks (wandering logs). I remind that in reiser4 all disk allocations are always "delayed", that is, performed at commit time. In other bits proxy device is the most ordinary brick like other devices-components of your logical volume.
Before adding to a logical volume, proxy device should be formatted like other bricks. Respectively, at format time you need to specify UUID and stripe size of your logical volume:
mkfs.reiser4 -U UUID -t STRIPE_SIZE DEV
In order to add a proxy device to your logical volume simply execute
volume.reiser4 -x DEV MNT
where DEV is the name of your properly formatted proxy device, MNT is mount point of your logical volume.
The procedure of adding a proxy device is always quick and is not accompanied with any data migration.
Flushing a proxy device
After being added to your logical volume, the proxy device automatically becomes a home of all new allocations, and hence, persistently gets filled with data. So user needs to take care on flushing data to the main storage. Without it the free space on your proxy device will end soon, and the advantage of having a proxy device will disappear.
Once free space on the proxy device gets ended, all allocations will automatically happen on the main volume. Note, however, that by default it will drop the overall performance (because of trying to commit all transactions at every write iteration). Optionally it is possible to choose a mode without any performance drop, however, in that mode proxy disk space will be used less efficiently.
Anyway, don't allow your proxy device to be completely filled with data, as it will nullify all the advantages of having a proxy-device!
Flushing proxy device can be performed via common migration procedure (the same procedure is used to migrate data when adding/removing a device to/from a logical volume). So, in order to flush your proxy device, just execute
volume.reiser4 -b MNT
where MNT is mount point of your logical volume.
Like every user-space application the flushing procedure may return error. The list of "regular" errors is:
EBUSY means that flushing procedure gave way to some other process of higher priority in the competition for resources (usually long-term locks on the storage tree) ENOMEM means not enough memory for some flushing subroutine ENOSPC means not enough space on main storage
In case of returned EBUSY you just need to repeat the flushing procedure. In other cases put efforts (free some disk space on your main storage, etc) to make sure that such errors won't happen next time and then repeat the flushing procedure.
If the flushing procedure was interrupted for some reason (e.g. system crash, hard reset), then simply repeat it in the next mount session for this logical volume.
Once the Burst Buffers stuff becomes stable, we'll implement automatic flushing of proxy device by a special kernel thread, which gets woken up every time when some block allocation happens on the proxy device. At the moment, we are making the user responsible for this.
With currently existing interface it is also possible to organize flushing efficiently. In the simplest case it can be done by various scripts like the following one:
while true; do do sync volume.reiser4 -b /mnt sleep 60 done
Smarter script would check space occupied by data on the proxy brick before flushing, etc.
Removing a proxy device from a logical volume
At any time you are able to remove proxy device from your logical volume. It is in the assumption that no volume operations like adding/removing a device to/from this logical volume are in progress at the moment of proxy device removal.
Removing a proxy device is absolutely similar to removing usual device form the logical volume. In particular, removal operation is always completed with data migration from the proxy-device to be removed to other devices-components of your logical volume.
Before removing a proxy device make sure that there are enough space on other devices-components of your logical volume. Note that disk space of meta-data brick is not counted in the case when the last one is not a member of DSA (Data Storage Array), i.e. is used to store meta-data only.
To remove proxy device from your logical volume simply execute
volume.reiser4 -r DEV MNT
where DEV is name of proxy device to be removed, MNT is mount point of your logical volume.
The procedure of removing a proxy device can return errors:
EBUSY means that the procedure of data migration gave way to some other process of higher priority in the competition for resources (usually long-term locks on the storage tree) ENOMEM means not enough memory for some data migration subroutine ENOSPC means not enough space on other devices
The mentioned errors should be handled in the same way that in the case of flushing.
If procedure of removing a proxy device was interrupted because of some reasons (system crash, or hard reset), then just follow instructions on deploying a logical volume after interrupted device removal.
Monitoring a proxy device
Monitoring a proxy device is performed by usual means, see e.g. this.
In order to check free space on your proxy device execute
volume.reiser4 MNT -p N
where N is serial number of the proxy device in your logical volume mounted at MNT. Don't forget to sync dirty pages before this! Number of busy data blocks can be found as difference (blocks used - system blocks).
Using meta-data brick as proxy device
It is possible to use meta-data brick of your logical volume as a proxy device. Before this make sure that it is not used to store data (otherwise, operation on its adding as proxy device will fail). To check it simply execute:
volume.reiser4 MNT -p 0
and check value of the field "in DSA". It should be "No". Otherwise, remove meta-data brick from data storage array by executing
volume.reiser4 -r MTD_NAME MNT
where MTD_NAME is device name of the meta-data brick, MNT is mount point of your logical volume. After removal completion add the meta-data brick as proxy device:
volume.reiser4 -x MTD_NAME MNT
WARNING: When using meta-data brick as proxy device, requirements on flushing are especially high, because in the case of no free space on meta-data brick you are not able to create new files on your logical volume.