[Tux3] [PATCH 02/10] don't use preallocation if BUFFER_PARANOIA_DEBUG is defined

[Daniel Phillips]

On Sunday 19 October 2008 02:27, OGAWA Hirofumi wrote:
> "Shapor Naghibzadeh" <shapor at gmail.com> writes:
> 
> >> The problem is - if dleaf doesn't have any group yet, dwalk_probe()
> >> initialize the pointers by end of buffer. So, we can't do dereference
> >> those pointers of dwalk, but some place does.
> >>
> >> I'm not reading all of dleaf stuff yet. So the patch may be wrong, or
> >> there may be more good fix.
> >> --
> >> OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>
> >>
> >
> > Yes, the change look correct to me.  I merged all your patches,
> 
> Thanks.
> 
> > inserting this one between 2 and 3 and all the tests passed after each
> > one.  I also now have a semi-automated system for testing patches and
> > patch sets posted to the list :)
> 
> That's great. Does it have (or plan) performance test too? I think, in
> future performance regression also will become issue.

Performance testing doesn't really make a lot of sense in user space,
the fuse interface is a huge bottleneck, likewise the synchronous Posix
IO calls.  We can start performance testing when we have a kernel port.
The kernel port can start as soon as we have a prototype of atom commit
working in user space.

Here is a first cut, partial list of tasks for the kernel port:

  - Buffer operations need to be adapted to work with page cache and
    bio instead of userspace synchronous Posix IO.

  - Much glue to vfs *_operations methods.

  - Mount options parsing, superblock load/save

  - Spinlocks for VFS ops

  - First cut btree, bitmap and atom table locking

This list is way incomplete, I just thought I'd start it now and flesh
it out as we get closer.

We will avoid the biggish job of converting any "non grata" C99 features
such as inline declarations for now by just disabling the C99 warnings
in kernel, and use defines/macros to make most of the user space code
compile in kernel just as it is, for the time being.

Spinlocks typically require that some high traffic code be refactored
in unnatural ways.  We will do this for the kernel code and backport
that code to userspace, either using empty macros in userspace or
perhaps SysV semaphores for a more realistic simulation.

We will start with simple minded per-inode monolithic locks for btree
access, allocation for now, then add high tech granular locks bit by
bit.

In kernel, nearly everything is parallel and asynchronous, unlike the
userspace code where the tux3 high level simulation is strictly single
threaded and fuse linearizes everything by default.  We could start to
work on the parallel aspects in userspace by going to pthreads and
pthread mutexes under fuse, but it is not clear that that would
actually save time versus just jumping straight into kernel with a
little bit of sandbox work using user mode linux in smp mode.  If
somebody else wants to take a run at adding pthreads to tux3fuse, they
would be more than welcome, but I will shift my own effort into kernel
pretty soon.

Regards,

Daniel

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3