* chunkd self-check question
@ 2009-12-03 3:55 Pete Zaitcev
2009-12-03 5:32 ` Jeff Garzik
0 siblings, 1 reply; 2+ messages in thread
From: Pete Zaitcev @ 2009-12-03 3:55 UTC (permalink / raw)
To: jeff; +Cc: Project Hail List
I need a way to scan all objects that an Chunk node keeps. There's
a function that does it already: fs_list_objs. Looking at it, is there
a reason why it uses readdir instead of tchdbiternext? In case of
self-checking, scanning directories is undesirable, because if an
object somehow (e.g. a hardware failure) ends existing in filesystem
but without a corresponding entry in the TC database, it will incorrectly
count as present.
-- Pete
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: chunkd self-check question
2009-12-03 3:55 chunkd self-check question Pete Zaitcev
@ 2009-12-03 5:32 ` Jeff Garzik
0 siblings, 0 replies; 2+ messages in thread
From: Jeff Garzik @ 2009-12-03 5:32 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: Project Hail List
On 12/02/2009 10:55 PM, Pete Zaitcev wrote:
> I need a way to scan all objects that an Chunk node keeps. There's
> a function that does it already: fs_list_objs. Looking at it, is there
> a reason why it uses readdir instead of tchdbiternext?
The TC database master.tch stores table data, not object data.
master.tch is a (table name)->(table identifier) lookup table.
The object "database" remains 100% filesystem-based, with a fixed-length
metadata header prepended to each object.
That means per-object lookup and retrieval is super-quick, with the
kernel's pagecache and i/dcaches working hard for us.
However, the list-objects operation requires that we open each object's
file, and read the fixed-length metadata header. Objects not belonging
to the authenticated user are then discarded from the list-objects output.
A truly server-punishing operation -- opening and reading EVERY file's
fixed length header -- but the thought was that list-objects would be so
infrequent (once daily? once per cluster boot?) that it would not
matter much.
If that assumption turns out to be invalid or unwise, we can certainly
change things (see below).
> In case of
> self-checking, scanning directories is undesirable, because if an
> object somehow (e.g. a hardware failure) ends existing in filesystem
> but without a corresponding entry in the TC database, it will incorrectly
> count as present.
I had considered storing object metadata in an additional TC database,
for a couple reasons: much faster list-objects and object metadata
retrieval, and storage of small objects.
If some future chunkd stores object metadata in a TC database, yes,
inconsistencies could arise.
Jeff
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-12-03 5:32 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-12-03 3:55 chunkd self-check question Pete Zaitcev
2009-12-03 5:32 ` Jeff Garzik
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.