Bug #694

UFS inode hash chain conversion to SLIST

Added by josepht about 7 years ago. Updated almost 5 years ago.

Status:ClosedStart date:
Priority:LowDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

The attached patch is my attempt to convert the i_next field in struct
inode to an SLIST. I'm not sure if I handled the initialization
correctly or if I handled the ilast part of ufs_ihashins() correctly.
It seems to me that a STAILQ may be a better choice since it seems
like all insertions are done on the tail of the list (queue).
Comments are welcome.

Thanks,
Joe

ufs_ihash.patch Magnifier (4.46 KB) josepht, 06/13/2007 12:43 AM

History

#1 Updated by dillon about 7 years ago

:The attached patch is my attempt to convert the i_next field in struct
:inode to an SLIST. I'm not sure if I handled the initialization
:correctly or if I handled the ilast part of ufs_ihashins() correctly.
:It seems to me that a STAILQ may be a better choice since it seems
:like all insertions are done on the tail of the list (queue).
:Comments are welcome.
:
:Thanks,
:Joe

Well, there's no reason to kmalloc() little slist header chunks and
assign them to ihashtbl. Just make ihashtbl an array of slist headers.

But, apart from that, an SLIST is not a good idea here, because
deletions rescan the list (look at the mess SLIST_REMOVE() does in
sys/queue.h). A TAILQ would work ok, but I don't think there's a big
enough reason to change the code to a TAILQ when the manual singly linked
list works just fine.

-Matt

#2 Updated by tuxillo almost 5 years ago

Is this going to be committed finally?

#3 Updated by corecode almost 5 years ago

I think we shouldn't.

#4 Updated by dillon almost 5 years ago

:Simon 'corecode' Schubert <> added the comment:
:
:I think we shouldn't.

I agree. There's no need to do it. It doesn't make UFS work any
better or worse.

-Matt
Matthew Dillon
<>

Also available in: Atom PDF