[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: How to generate a large file allocating space

--On 4 November 2010 13:46:38 +0100 Bodo Thiesen <bothie gmx de> wrote:

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

Alex Bligh

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]