linux-kernel - Re: [osd-dev] [PATCH 7/9] exofs: mkexofs

Open Source and information security mailing list archives

Date:	Tue, 13 Jan 2009 15:32:33 +0200
From:	Benny Halevy <bhalevy@...asas.com>
To:	Jeff Garzik <jeff@...zik.org>
CC:	linux-scsi <linux-scsi@...r.kernel.org>,
	Matthew Wilcox <matthew@....cx>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Avishay Traeger <avishay@...il.com>,
	open-osd development <osd-dev@...n-osd.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Al Viro <viro@...IV.linux.org.uk>,
	Boaz Harrosh <bharrosh@...asas.com>
Subject: Re: [osd-dev] [PATCH 7/9] exofs: mkexofs

On Jan. 13, 2009, 15:24 +0200, Jeff Garzik <jeff@...zik.org> wrote:
> Benny Halevy wrote:
>> IMO the main advantage of moving block allocation down to the OSD target
>> is more apparent with distributed file systems a-la pNFS over objects
>> where paralleling that task is a key for scalable performance.
>>
>> The thing is that the target needs to implement its own mapping from
>> object logical offsets into disk blocks and this is usually done
>> using some kind of a (possibly trimmed down) local file system.
>> Therefore the I/O performance of a single OSD is likely to be similar
>> to a single file server's.
> 
> Well, modern SATA devices are already mini-filesystems internally, when 
> you consider logical block remapping etc.
> 
> And the claim by drive research guys at the filesystem/storage summit 
> was that OSD offered the potential to better optimize storage based on 
> access/usage patterns.
> 
> (of course, whether or not reality bears out this guess is another question)

That's true for multi-user access where knowing the context for each I/O
request - i.e. the object that holds it provides a crucial hint for
read-ahead and write allocation, where for a dumb device that doesn't
know anything about the filesystem's internals, it's much harder to
associate different blocks with their respective containers, or "streams"
(in case the container is typically accessed in a sequential pattern).

> 
> 
>> I can understand representing a single object as a block device (although I
>> think that using a file for that should be good enough and easier) but
>> why representing the whole OSD as a block device?  The OSD holds partitions
>> and objects each with attributes and OSD security related support.  Hence
>> representing that in a namespace using a filesystem seems straight forward.
> 
> I am actually considering writing a simple "osdblk" driver, that would 
> represent a single object as a block device.
> 
> This would NOT replace exofs or other OSD filesystems, but it would be 
> nice to have, and it will give me more experience with OSDs.

That's awesome!
It be really interesting to benchmark one against the other.

Benny

> 
> 	Jeff
> 
> 
> _______________________________________________
> osd-dev mailing list
> osd-dev@...n-osd.org
> http://mailman.open-osd.org/mailman/listinfo/osd-dev

--
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/

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