Sorry, Sujit K M -----Original Message----- From: Sujit Karataparambil Sent: Tuesday, December 04, 2007 3:06 PM Cc: '[EMAIL PROTECTED]'; 'Richard L. Hamilton' Subject: RE: [storage-discuss] Project Proposal: Device Mapper
I would Like to know if the Project can Perform without much Changes To the volume drive already present in the framework. It Would be much Better if one would do that. Simply by being an C,C++ Library in the Kernel. This would lead to better performance and also the kernel might be Left Without Modifying the Volume Drive Already Present. Also it would be much Better in case x86 Vs Sparc Implementation. Thanks for Any Suggestion, Sujit K M -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard L. Hamilton Sent: Tuesday, December 04, 2007 2:50 PM To: [email protected] Subject: Re: [storage-discuss] Project Proposal: Device Mapper Would this be one of the tools that might eventually help getting labelling out of device drivers and filesystems, and into a set of common functions that just pass back the partition info to the driver (or the size of the reserved area at the beginning of the slice to the filesystem)? I've always hated that quite a bit of disk label knowledge is embedded in drivers and filesystems, rather than in separate support routines (which could enable smarter or more consistent (between x86 and SPARC)) handling of trickier cases like logical partitions and so on. To the extent that drivers could delegate label parsing, partition setup and corresponding minor device creation to support routines, they'd surely be simplified. And think about what pcfs has to know about FDISK partitions: if someone wanted to create a native (not just FUSE) port of a pre-existing PC filesystem (ntfs, ext2fs, whatever), would it also have to be burdened with such knowledge? I can understand that access to media is essential, and has been tweaked quite a bit. But if that continues to excuse aggregation rather than design, it will IMO all just collapse under its own weight eventually. And I find it hard to believe that the present approach is anywhere near as well layered as it could or should be. This message posted from opensolaris.org _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
