On Wed, Feb 27, 2013 at 12:52:50PM -0800, Alex Elsayed wrote:
> Also, in talking on IRC with Hugo Mills he helped me realize another issue -
> specifically, that a.) DIO to compressed data falls back to buffered IO, and
> b.) (at least according to the wiki) the compress_force mount option takes
> precedence over the NOCOMPRESS file flag.
>
> Thinking about it further, I realized that individual extents could be
> compressed, at which point this could get rather onerous on swapon since we
> might well need to check each and every extent to make sure it isn't
> compressed.
There are a few limitations I can think of:
* the file has to be nocow (stable block ranges)
* no compression for the swap file (due to nocow)
* snapshot of the swapfile would work probably the same way as in any
other nocow file, but may imply unexpected or unwanted locking and
interfering with swap.
* relocation must not move the file extents, which makes balance
still possible, but it may not be able to satisfy the filter
requirements (the 1G chunks are basically pinned until the swap file
is active)
- this affects 'device remove', 'fi resize'
- depends on the raid profile used for the file, raid 0 is likely to
pin all devices
david
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
