On 04/12/2010 01:32 AM, Alexandre Moreira wrote: > Ok, first for all, please excuse me if this is not the best place to > ask such a question. I just couldn't find a place which fits best, so > I decided to give it a try. If at all inconvenient I'll just drop the > topic. Don't worry, your message fits perfectly fine here. > The thing is, after stalking, erm.... I mean, reading, the list for > quite a while, I stumbled into a reference to "Practical File Systems > Design" by Giampaolo and I'm finding it a most interesting read. One > thing that caught my attention, and I'm not sure if I understood > correctly is: Does every attribute past the "small_data" storage take > a least two data blocks in disk? If so, isn't this excessive waste? > Just to make sure where I come from: I'm thinking that the attribute's > inode takes one whole block, while it points to at least one block of > data. It is indeed excessive waste, but it's even worse than that: if the small_data region is filled up, an attribute directory is created for the node - this is a full fledged directory that takes up another inode block plus at least 2048 bytes (so 1 to 2 blocks depending on your block size) for the B+tree. Then, each additional attribute is a file, too, so it has at least two block as well (one for the inode, one for the file data). Luckily, at least with a block size of 2048 bytes, you will rarely hit that limit. > Of course, I'm not advocating any change in this regard, even if > wasting a lot, because that would mean a major incompatibility. It's > just that I got quite interested in the internals of BeOS, and > therefore Haiku, and I'm trying to understand it more closely. BFS has a number of issues like that that would require us to break on disk compatibility if we wanted to solve them (which we'll do at some point, but not before R1). Bye, Axel.