Re: [Apt-proxy-users] endless recycling

[Micha <ear...@gm...>]

I'm sorry my question lead to some judging expressions here.
OTOH i find the thread really constructive, and  i'm glad to see no one's f=
laming.
I'm no programmer, but as my boxes' design somehow depends on apt-proxy, i =
like to make some notes, too.

> On Mon, 31 Jan 2005, Chris Halls wrote:
> > The ideas are good but they do ignore the two use cases I mentioned tha=
t were
> > the primary reasons for the existence of the database (noatime mounts a=
nd
> > unwanted updating of atime by other programs).
Why noatime mounts ? I guess (but i don't really know) as a try to accelera=
te the access time. But do you really think on a modern HD this could be a =
bottleneck, even when serving 50 machines ?
So why not make atime mandatory, and suggest the standard atime mount at in=
stallation time, and there could affitionally be a check if no atomes can b=
e found, and an appropriate error message. I believe access time is somethi=
ng a filesystem is designed for, why not leave the job to where it belongs.=
 It should be faster than all the database operations, anyway.

Then there still would be the problem with 'foreign atime updating'.
I imagine something like backup or indexing, for example the locate db.
As far as i can see, they onlymodify atime, never mtime.
So perhaps the ideal solution would be to ditch atime checking.
My first idea is, use mtime where you used atime, and introduce a slight fi=
le modification for the cases where ap needs mtime. ext3 and reiser support=
 user specific attributes, or access control lists, for example. But the pr=
oblem to handle many different FS types would be clearly too much, and stil=
l there's ext2. So you only can rely on a lowlevel common unix feature.
I suggest working with ctime, the inode modification time.=20
I've found some notes in the manpage of 'ls' but i'm no specialist here. It=
 said permissions, or renaming, modify ctime but not the others. So perhaps=
 you can (touch and) use that to determine when a file was downloaded, and =
touch mtime when a file is requested ?
Again, i'm no programmer, and know little of filesystems. It only appears t=
o me that managing file time stamps at all would be redundand, as the files=
ystem itself should be the best 'database'.
And _they_ do a lot of effort to check and ensure integrity.
So why not leave the job to them ?
Perhaps it means you've got more time for long-term things...

btw. I didn't mean to abandon the whole database concept. But perhaps you c=
an reserve the db for information that never can be managed by the FS, and =
needs to be updated or requested rather extensivly. I don't know your roadm=
ap, of course.

Jonathan Koren <jk...@cs...>:
> Are you proposing to compare a checksum every time a file is served ?
Maybe they think of security checks against corruped or hacked files ?=20


greetings, mi.





  =B0
 /\/