Michael Jung mjung@iss.tu-darmstadt.de writes:
Changelog: Cache the canonicalized unix paths, which correspond to dos devices.
I don't think you want to do that. The goal of the new symlink scheme is to make it possible to change drive config on the fly, caching it would defeat that.
On Thursday 16 June 2005 17:02, Alexandre Julliard wrote:
I don't think you want to do that. The goal of the new symlink scheme is to make it possible to change drive config on the fly, caching it would defeat that.
You mean like while an application is running? Wouldn't that break a lot of applications, which store filenames in memory during runtime?
In the current implementation, for every shitemid that is constructed, all drives are queried and their paths are canonicalized, which is a lot of disk i/o and string copying. Unixfs is really painfully slow. I guess we need some caching scheme, but if you don't like the current one, I'll give it some more thought.
Bye,
From: "Michael Jung" mjung@iss.tu-darmstadt.de
In the current implementation, for every shitemid that is constructed, all drives are queried and their paths are canonicalized, which is a lot of
disk
i/o and string copying. Unixfs is really painfully slow. I guess we need
some
caching scheme, but if you don't like the current one, I'll give it some
more
thought.
Can't we just invalidate the cache if we notice things have changed?
On Thursday 16 June 2005 23:11, Dimi Paun wrote:
Can't we just invalidate the cache if we notice things have changed?
Yes, that should'nt be too hard. Would that be ok, Alexandre?
Bye,
Michael Jung mjung@iss.tu-darmstadt.de writes:
You mean like while an application is running? Wouldn't that break a lot of applications, which store filenames in memory during runtime?
No, you can remap drives on Windows too.
In the current implementation, for every shitemid that is constructed, all drives are queried and their paths are canonicalized, which is a lot of disk i/o and string copying. Unixfs is really painfully slow. I guess we need some caching scheme, but if you don't like the current one, I'll give it some more thought.
I think the whole canonicalization thing is suspect; you should never compare Unix path strings. If you have to compare paths you should use stat and compare device/inode.
On Thu, Jun 16, 2005 at 11:26:45PM +0200, Alexandre Julliard wrote:
I think the whole canonicalization thing is suspect; you should never compare Unix path strings. If you have to compare paths you should use stat and compare device/inode.
Except that some FS have difficulty generating unique inode numbers. (There is no answer to the problem though)
David
-
Alexandre Julliard -
David Laight -
Dimi Paun -
Michael Jung