How to generate a large file allocating space
alex at alex.org.uk
Thu Nov 4 18:22:39 UTC 2010
--On 4 November 2010 13:46:38 +0100 Bodo Thiesen <bothie at gmx.de> wrote:
> <adilger at dilger.ca> hat geschrieben:
>> * On 2010-10-31, at 09:05, Alex Bligh wrote:
>>> I am trying to allocate huge files on ext4. I will then read the extents
>>> within the file and write to the disk at a block level rather than using
>>> ext4 (the FS will not be mounted at this point). This will allow me to
>>> have several iSCSI clients hitting the same LUN r/w safely. And at
>>> some point when I know the relevant iSCSI stuff has stopped and been
>>> flushed to disk, I may unlink the file.
> Question: Did you consider using plain LVM for this purpose?
> By creating a
> logical volume, no data is initialized, only the meta data is created
> (what seems to be exactly what you need). Then, each client may access one
> logical volume r/w. Retrieving the extents list is very easy as well. And
> because there are no group management data (cluster bitmaps, inode bitmaps
> and tables) of any kind, you will end up with only one single extent in
> most cases regardless of the size of the volume you've created.
Plain LVM or Clustered LVM? Clustered LVM has some severe limitations,
including needing to restart the entire cluster to add nodes, which
is not acceptable.
Plain LVM has two types of issue:
1. Without clustered LVM, as far as I can tell there is no locking
of metadata. I have no guarantees that access to the disk does not
go outside the LV's allocation. For instance, when a CoW snapshot is
written to and expanded, the metadata must be written to, and there
is no locking for that.
2. Snapshots suffer severe limitations. For instance,
it is not possible to generate arbitrarily deep trees of snapshots
(i.e. CoW on top of CoW) without an arbitrarily deep tree of loopback
mounted lvm devices, which does not sound like a good idea.
I think you can only use lvm like this where you have simple volumes
mounted, and in essence take no snapshots.
To answer the implied question, yes we have a (partial) lvm replacement.
>> GFS and OCFS both handle shared writers for the same SAN disk (AFAIK),
> They are SUPPOSED to do that - in theory
We have had similar experiences and don't actually need all the features
(and thus complexity) that a true clustered filing system presents.
More information about the Ext3-users