From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans Reiser Subject: Re: Some questions about Reiser4 Date: Sat, 10 May 2003 20:20:47 +0400 Message-ID: <3EBD26DF.2090801@namesys.com> References: <000c01c30b6a$d7f12590$0200a8c0@xpstation> <3EAA8008.4020401@namesys.com> <000b01c30bf7$bf47b080$0200a8c0@xpstation> <3EAA98EB.3040702@namesys.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <3EAA98EB.3040702@namesys.com> List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Yury Umanets Cc: Fred -- Speed Up -- , reiserfs-list@namesys.com Yury Umanets wrote: > Fred -- Speed Up -- wrote: > >> Now that I know that keys depend on inode numbers, I can understand some >> points a far better way., thanks a lot ;) >> > Inode number has the different nature in different filesystems. > >> >> - But I didn't knew Reiser4 was using inodes, as I thought everything >> was >> stored in the tree ... now, you say Reiser4 stores directories and small >> files in the tree, but isn't that kind of blobs Reiser4 would not use ? >> > Hans will answer this in monday. > >> - In the official documentation, it is said that blobs have moved out >> from >> Reiser4, is that true ? > Yes. >> >> > And this one. > >> - In case of a small file being written to the disk, even if it is >> kept in >> the tree you assign it an inode number ? >> > Of course. Each file contains of the following: > (1) stat data (inode in VFS notation) > (2) some body (tails, extents, directory items, etc) > > If we do not assign inode to small file, how VFS will handle it? And > how reiser4 will find it in the tree? We assign an objectid. We do not have inodes. > > >> - What do you really mean by "flush" : can it be considered as a >> mantainance >> operation that's running from time to time to clean the tree ? >> > Yes. In general flush is reiser4 subsystem, supposed to flush slums > (dirty pieces of tree) to the disk. Of course those slums should be > served in particular maner (packing, allocation) I have written about it. > >> I saw that >> programs can ask Reiser4 to flush, does flush in this case mean >> "physically >> write data to the disk" ? >> > It does mean and this too. > >> - When resolving a path, you still need to physically open >> directories, this >> means searching through the tree : isn't there another data structure >> intended to cache path data so that resolving a path operation doesn't >> include searching the main tree ? >> > Actually there is so called CBK cache. This is simple mechanism to > satisfy tree lookups (by a key) without searching though the tree itself. > But it is used not only in path serach time, but also in other cases > (for instance, for seraching file body item at particular file offset). > >> I thought the semantic layer had its own >> structure, not directly dependent on the main tree, for performance >> concerns. >> > >> - There is no case of multiple extents use in the official doc, but >> as you >> explained to me they are commonly used : do you need inodes to store >> extent >> pointers, > no >> or are they kept together in the tree ? > yes. >> >> > I can't comprehend you. > >> >> Be sure you'll have full regard on the documents I'm publishing about >> Reiser4. >> >> Than you again, >> > Okay, thanks > >> >> Fred >> >> >> >> >> > > -- Hans