linux-kernel - Re: [help]How to block new write in a "Thin Provisioning" logical volume manager as a virtual device driver when physical spaces run out?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5f7c1d2c0806021022t67d07733p47b78d351dcf63b6@mail.gmail.com>
Date:	Tue, 3 Jun 2008 01:22:28 +0800
From:	"Xiaoming Li" <forrubm2@...il.com>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>
Cc:	"Rik van Riel" <riel@...hat.com>,
	"Dave Chinner" <david@...morbit.com>,
	"Christoph Hellwig" <hch@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [help]How to block new write in a "Thin Provisioning" logical volume manager as a virtual device driver when physical spaces run out?

Dear Alan,

On 5/29/08, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> > As a result, with LVM, you can never export a "logical volume" with
> > claimed storage space larger than of the underlying physical storage
> > devices (e.g. SATA disks, Hardware RAID array etc.); but with ASD, you
> > can export "logical volumes" which have much larger logical storage
> > space.
>
> Why do that ?
>
> > Does anyone have some ideas for a better solution?
>
> Take one file system such as ext3, or even a cluster file system like
> GFS2 or OCFS. Create top level subdirectories in it for each machine.
> Either export the subdirectory via NFS. Alternatively mount the clustered
> file system somewhere on each node and then remount the subdirectory into
> the right place in the file tree
>
> (And for a clustered/shared pool root you can use pivot_root() to start
> from initrd or local disk and then switch to running entirely within the
> clusterfs)

Thank you for your quick reply.

Yes, in our ASD system, we have implemented "Thin Provioning" on block
level, and we do have the problem of "no way to free space". Thank Rik
van Riel for pointing this out.

However, I want to ask, is there _any need_ to implement "Thin
Provioning" on block level rather than FS level?
In my opinon, there are some reasons why we implemented "Thin
Provioning" on block level:
1. We can use _all_ types of FS on our ASD device.
2. In our current system, we use some other virtual device drivers to
provide other features, like snapshot, cahce management, exporting as
an iSCSI target in a SAN, etc. Please note, all of these virtual
device drivers have been developed already.
3. Some storage vendors (e.g. EMC) have their own "Block-based thin
provisioning" product; they must have enough reasons to do so.
Please check the following URL for reference:
http://www.wikibon.org/Maximizing_storage_returns_from_your_EMC_relationship#Strategic_fit_for_EMC_in_key_storage_modernization_projects
Then search the string "Block-based thin provisioning".
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/