Hi Peter,
From the classic TR 3001:
"Like Episode, WAFL uses files to store meta-data. The three most important WAFL meta-data files are the inode file (which contains all inodes), a free block bitmap file, and a free block count file. Keeping meta-data in files allows meta-data blocks to be written anywhere on disk. This is the origin of the name WAFL, which stands for Write Anywhere File Layout. WAFL has complete flexibility in its write allocation policies because no blocks are permanently assigned to fixed disk locations as they are in the Berkeley Fast File System (FFS)."
So data blocks and inodes are stored separately. This is why snapshots are so darn fast...OnTap just copies those files over. This is an incredible innovation.
Techno-history buffs may also be interested in checking out the original paper describing WAFL that was presented at Usenix '94 at:
http://www.usenix.org/publications/library/proceedings/sf94/full_papers/hitz...
But I'm pretty sure that the reason ls on a directory with lots of objects takes a long time is that you run out of CPU on the single filer head. Generic FS issue which can't be solved unless you have a clustered NAS system which can use multiple heads that take up the extra load of sorting files and so on.
Full disclosure: I work for one of those clustered NAS companies :-)
Regards, Sandeep Cariapa
--- "Peter D. Gray" pdg@uow.edu.au wrote:
On Mon, Oct 22, 2007 at 06:26:56PM -0700, Blake Golliher wrote:
I'd argue that this is general file system issue,
not so much a wafl
issue. I don't think wafl is particularly slow at
this workload
The problem itself is a general filesystem issue I agree.
However, my understanding is that wafl stores the metadata with the file, I assume as the first block. UFS stores the metadata in inodes, and they are not stored with the file, but the system tries to keep inodes "close" to the file. Inodes reside together with other inodes so a single read can pick up a lot of inodes.
So to me it seems possible thatUFS may have an advantage when accessing metadata because the number of individual block reads (and hence seeks etc) could be a lot less.
Obviously statistics come into play a lot here. Thats why I am talking in generalities.
If anything I say above is incorrect, please correct me. I am not a FS developer.
Regards, pdg
--
See mail headers for contact information.