Re: [fuse-devel] mobifs: part two, aggregatefs

[Michael R. <fb0...@ra...>]

mobi phil wrote:
>> Oh great. So now we see that you have some real usage data for this
>> solution. It is becoming more interested. I guess you should have
>> started with that..
> If you look back, I mentioned this already.

Only with size - which is not actually useable data..

>> You took for granted things that follow from your measurements that
>> don't even give the same result for me now that you described them in
>> details (more below). On the other hand, your claim that you need to
>> mount a FUSE instance for each file (in the previous thread) had not had
>> time to be forgotten.. You told it confidently because you were sure in
>> your data, you had the reason to be confident, but gave little reason to
>> believe you.
> 
> I am confused here. What I was talking about in the prev. thread was
> an oposite usage of the same pattern. Goin from composed (aggregated)
> data to components, here from components to aggregated data. The main
> pattern is that you might be in situation, where you want to access
> parts of an entity separatelly, or the whole. It is up to the
> situation/imagination/etc what would fit better. I can give you even a
> more sofisticated example. Imagine you have a database around 1GB.
> With several tables/with several text fields. You want to do a sort of
> "ala police" investigation, about different pieces of texts. You could
> write stupid sql statements and spend hours with them, instead you
> could use a fuse fs that maps the structure of the db to files, then
> you can aggregate those files into one files. Of course you could
> write a driver that maps the full db into one text file. Load that
> into vim, and searching will be a pleasure :)

If it is an SQL DB, dumping out 1GB is not a pleasure.. Although a few
FS filters may help the dumping..

>> NONE -N, I have gigantic .vimrc with many autocommands which would
>> negatively influence the process so I disabled it). For me it also does
>> thousands of context switches - it reads in 64K increments.
> Yes, but once in memory, no context switch, well at least no buffer
> copy from kernel etc.

It looks like it rereads the file.. At least, no "instant" search for me
with 2GB of RAM installed in my notebook.

>> Given that any indexing solution will actually work instantly with the
>> same amount of maintenance (cron.daily), it looks like the raw idea is
>> not enough to make people intrigued.
> indexing inside vim would be a great thing. I a thinking about that.
> Vim is a great tolo, unfortunatelly adding any functionality on top of
> it is almost impossible, due to a little chaotic organisation of data
> structures, no threading etc.

You take external scripts, I guess...

>> And your example is, unfortunately,
>> exactly an example where there are different solutions. So you need
>> specific questions or a link to implementation..
> So far, to be honest I feel a bit discouraged, I will go for some
> quick and dirty solution for fuse driver,

There is a simple solution, so I think you will succeed

>> Well, if you have data to back your claims, we cannot convince you, and
>> some attack (like mine) can even make you quote the data which seems a
>> big win for a general discussion.
> yes. yes. But it is frustrating to spend time to collect data to
> convince people, when you have nothig to win. :)

Heh, if you can implement it easily on yourself, you have nothing to
gain here. A ready implementation will attract a few contributors anyway..