[haiku-development] Re: User interaction while mounting filesystems

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 05 Apr 2010 11:54:31 +0200

Hi Janito,

Janito Ferreira Filho <jvffprog@xxxxxxxxxxx> wrote:
> sorry for the two different replies, but I thought it would better 
> organize the information flow. Please tell me if it's better 
> etiquette
> to join them into a single reply. Thanks =).

If you do something wrong, I guess someone will take the time to point 
it out. In any case, it wouldn't be a biggie anyway.

> > IOW you need a mechanism where you (the one initiating the mounting 
> > procedure) decide how the information/requests are presented.
> > File systems already have a userspace add-on that could deliver 
> > functionality in this regard.
> Okay, just like the Linux (or probably POSIX, since I think it's 
> easily ported)
> e2fstools. How does it work on Haiku? Is there a tracker add-on, and 
> a separate
> terminal tool for mounting? What tools would be required? Or would it 
> be
> better to port e2fstools?

The e2fstools might help you in implementing specialized functionality, 
but not much more, I would guess.
In Haiku, the disk-system add-ons (in src/add-ons/disk_systems) are 
used only by the disk device API (which is mostly hidden in 
headers/private/storage). IOW the add-ons exports functionality used by 
that API in order to repair the volume or similar things.
That API can be used by command line tools as well as by Tracker to 
show an appropriate UI for each use case. 
You would need to extend the disk device API as well as the internal 
add-on interface to support something like that.

> It's log is replayed in the sense it does write blocks that are ready 
> in the journal?
> Even in read-only?

Usually, you cannot mount such a volume read-only. In BFS, the log size 
isn't that large, so you cannot have a large log to replay, so 
replaying in memory only would certainly be possible.

> Would it be wasteful to cache the blocks to be altered in memory 
> (without
> committing the journal) when mounting in read-only? This way we don't 
> alter
> the data on the device (true read-only) and we still have a 
> consistent file system.

It would be wasteful, but it would also work if the log is small. In 
some cases (a possibly corrupted file system) this could even be a 
welcomed functionality, as propagating the log entries could also cause 
extra damage on the file system if the log is corrupted itself (this 
happened to me once with BFS due to broken memory).


Other related posts: