Layer violation

The ever reoccuring criticism that ZFS gets from some Linux luminaries and even more often from admins at customers sites is the fact, that we didn´t use the well known layering (files to inodes to volume LBA to RAID LBA to disk LBA) and seemed to condensed all functionality into the filesystem. I want to make two comments to this . At first i find this a little argument a little bit strange. Okay, it´s a widely used and well known architecture. But It´s not the only and true way to store data on rotating rust. Jeff can explain this much better. Second: Most of the critics of ZFS seemed to look on it only in a cursory way. The vastly simplified administration of ZFS in regard of creating filesystem doesn´t mean that we developed a filesystem with integrated volume manager. Think of ZFS as a data management system for use with multiple front ends. One of this front ends ist the ZFS Posix Layer, giving you a posix compliant way to access the pool as an filesystem. Another frontend is the zvol-Mechanism. With this mechanism you can use the datapool as an volume in parallel to filesystems that exists on the same datapool. It´s perfectly valid use case to create an ufs filesystem (or via iSCSI even a ext3fs or NTFS filesystem) on a zvol, without loosing the advantages of ZFS. At the end, it would be even possible to connect applications directly to the data management unit, for example a mysql or a postgres directly accessing the pools. Thus you would circumvent all the semantics of volumes and filesystems, still without loosing the advantages of ZFS. So it isn´t a monolithic and undividable amalgam. It looks only this way to the cusory viewer who don´t dig into the inner concepts, as there were a huge focus to augment the fundamental advantages of the concepts behind zfs (like no fixed one-volume/one-fs structur or no predefinition of the allocation of space to certain filesystems by the partition table) with a really easy administration. Most of the times, when you create a volume, you want a filesystem in it. So: Why should we not do this in one step? And even when you don´t want to use the pool for filesystems, it won´t hurt you. ( I´ve even heard of someone who use this automatically created filesystem for storing the application using the zpools and docs that use the zvols in the zpool. Whenever she export/import the zpool to a different system, the applications and tools wander with the zpools. Neat idea.) Nevertheless the new layering gives the upper layers more knowledge about the physical side of storing informations on dics, enabling such neat things like selective resilvering of used blocks as a simple example (think about a syncing of new disc in a RAID that syncs the most important files at first. While not implemented at the moment, it´s perfectly possible with ZFS. With the old world order: Impossible, as the RAID-Controller has no knowledge of something like files)