4 . 8
AT T R I B U T E S
59
indirect blocks simplifies to a series of divisions (shifts) and modulo
operations.
4.8
Attributes
A key component of BFS is its ability to store attributes about a file with
the file. An attribute is a name/value pair. That is
PhoneNum = 415-555-1212
is an attribute whose name is
PhoneNum
and whose value is
415-555-1212
.
The ability to add attributes to a file offers a great number of possibilities.
Attributes allow users and programmers to store metainformation about a
file with the file but not in the file data. Attributes such as
Keywords
,
From
,
Type
,
Version
,
URL
, and
Icon
are examples of the types of information that
someone might want to store about a file but not necessarily in the file.
In BFS a file may have any number of attributes associated with it. The
value portion of an attribute can have an integral type (int32, int64, float,
double, or string) or it can be raw data of any size. If an attribute is of an
integral type, then, if desired, BFS can index the attribute value for efficient
retrieval through the query interface (described in depth in Chapter 5).
The BeOS takes advantage of attributes to store a variety of information.
The email daemon uses attributes to store information about email messages.
The email daemon also asks to index these attributes so that using the query
interface (e.g., the find panel on the desktop) we can find and display email
messages. The text editor supports styled editing (different fonts, colors, etc.),
but instead of inventing another file format for text, it stores the style run
information as an attribute, and the unblemished text is stored in the regular
data stream of the file (thus allowing the ability to edit multifont source code,
for example). And of course all files on the system have a type attribute so
that it is easy to match programs that manipulate a given MIME type with
files of that type.
With that rough sketch of what attributes are and how they are used, we
can now look at the implementation. BFS stores the list of attributes associ-
ated with a file in an attribute directory (the
attributes
field of the
bfs inode
structure). The directory is not part of the normal directory hierarchy but
rather "hangs" on the side of the file. The named entries of the attribute
directory point to the corresponding attribute value. Figure 4-2 shows the
relationships.
This structure has a nice property. It reuses several data structures: the
list of attributes is just a directory, and the individual attributes are really
just files. This reuse eased the implementation considerably. The one main
deficiency of this design is that it is also rather slow in the common case of
having several small attributes.
To understand why storing all attributes in this manner was too slow,
we have to understand the environment in which BFS runs. The primary
Practical File System Design:The Be File System
, Dominic Giampaolo
page 59