Welcome to the Reiser4 Wiki, the Wiki for users and developers of the ReiserFS and Reiser4 filesystems.

For now, most of the documentation is just a snapshot of the old Namesys site (archive.org, 2007-09-29).

There was also a Reiser4 Wiki (archive.org, 2007-07-06) once on pub.namesys.com.

Proxy Device Administration

From Reiser4 FS Wiki
Revision as of 19:06, 2 May 2020 by Edward (Talk | contribs)

Jump to: navigation, search

Before working with proxy devices you need to understand basic principles of reiser4 logical volumes, including backgound and administration bits.


Contents

Adding a proxy device to a logical volume

You are able to add a proxy device to your logical volume at any time. Currently only one proxy device per logical volume is supported. Also there a restriction that no volume operations (like adding/removing a device to/from this logical volume) should be in progress at the moment of adding a proxy device. 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 proxy 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 it 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 be ended soon, and the advantage of having a proxy device will disappear.

When free space on the proxy device gets ended, allocation will automatically happen on the main volume. Note, however, that by default it will slow down the overall performance, just because it is rather expensive to check, that free space on your proxy device has really ended.

So don't allow your proxy device to be completely filled with data! There is one more option though: when reservation on the proxy device gets ended, allocation will happen on the main volume. In this case no performance drop will happen, however, disk space of your proxy device will be used less efficiently (as reservations are performed basing on estimations, some of them are rather rough).

Flushing proxy device is 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 tiering stuff is 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.

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
	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 (see section above).

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 its 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.

Personal tools