DazukoFS 3.1.3-rc1 posted

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

DazukoFS 3.1.3-rc1 posted

John Ogness-9
Hi,

The first release candidate for 3.1.3 has been posted. The changes include:

- Process masking has been changed to address some concerns[0].

- A couple mmap() write functions were implemented to hopefully fix
  some kernel crashes reported[1].

- As discussed, DazukoFS has problems[2][3] if a registered process
  hits its maximum open files limit. Special error handling was added
  to abort and set errno to EIO for the group device read if this
  occurs.

I am running DazukoFS 3.1.3-rc1 on ext4 for Linux 2.6.32.2 (ppc).

John Ogness

[0] http://lists.gnu.org/archive/html/dazuko-devel/2009-11/msg00000.html
[1] http://lists.gnu.org/archive/html/dazuko-devel/2009-10/msg00002.html
[2] http://lists.gnu.org/archive/html/dazuko-help/2009-10/msg00012.html
[3] http://savannah.nongnu.org/bugs/?28101

--
Dazuko Maintainer


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: DazukoFS 3.1.3-rc1 posted

Lino Sanfilippo
John Ogness wrote:
> - A couple mmap() write functions were implemented to hopefully fix
>   some kernel crashes reported[1].
>
> [1] http://lists.gnu.org/archive/html/dazuko-devel/2009-10/msg00002.html
>  

Hi,

the reason for these kernel crashes is the use of the
generic_file_aio_write()
kernel api.
Using these genericXXX functions in the dazukofs file operations
is always dangerous, since they might require function definitions, that
are not provided (and not needed) by dazuko (i.e all kind of functions that
are called to physically write data to disk).

In this case generic_file_aio_write() marks the pages that belong to the
dazukofs inodes as dirty, which tells the kernel that they should be
written to disk. In turn the kernel calls the write_begin() and writepage()
functions of dazukofs address_space.
Note that these functions should never be called by the kernel, since
dazukofs
does not write any data to disk itself.

If we want dazukofs to provide functions for async write/read, we have
to do
an own dazukofs wrapper (see dazukofs_mmap()) that checks if the lower
filesystem is
prepared to handle these functions and if so directs calls to the lower
filesystem.


Regards,
Lino Sanfilippo

Geschäftsführender Gesellschafter: Tjark Auerbach
Sitz der Gesellschaft: Tettnang
Handelsregister: Amtsgericht Ulm, HRB 630992
ALLGEMEINE GESCHÄFTSBEDINGUNGEN
Es gelten unsere Allgemeinen Geschäftsbedingungen
(AGB). Sie finden sie in der jeweils gültigen Fassung
im Internet unter http://www.avira.de/agb
***************************************************


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: DazukoFS 3.1.3-rc1 posted

John Ogness-9
On 2010-01-04, Lino Sanfilippo <[hidden email]> wrote:
> the reason for these kernel crashes is the use of the
> generic_file_aio_write() kernel api.
>
> Using these genericXXX functions in the dazukofs file operations
> is always dangerous, since they might require function definitions, that
> are not provided (and not needed) by dazuko (i.e all kind of functions that
> are called to physically write data to disk).

It is dangerous only if it is not what we want (or is being used
incorrectly by us). I want to avoid copy/pasting code.

> In this case generic_file_aio_write() marks the pages that belong to
> the dazukofs inodes as dirty, which tells the kernel that they
> should be written to disk. In turn the kernel calls the
> write_begin() and writepage() functions of dazukofs address_space.
> Note that these functions should never be called by the kernel,
> since dazukofs does not write any data to disk itself.

Agreed. They should not be called. I assume we are doing something
wrong.

> If we want dazukofs to provide functions for async write/read, we
> have to do an own dazukofs wrapper (see dazukofs_mmap()) that checks
> if the lower filesystem is prepared to handle these functions and if
> so directs calls to the lower filesystem.

I would prefer to know why generic_file_readonly_mmap() isn't working
as we expect: as read-only. Perhaps we are simply using the generic
functions incorrectly. DazukoFS is not the only filesystem that does
not support mmap-writing. Others are jffs2, afs, 9p.

John Ogness

--
Dazuko Maintainer


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel
Reply | Threaded
Open this post in threaded view
|

Re: DazukoFS 3.1.3-rc1 posted

Lino Sanfilippo
John Ogness wrote:
> I would prefer to know why generic_file_readonly_mmap() isn't working
> as we expect: as read-only. Perhaps we are simply using the generic
> functions incorrectly. DazukoFS is not the only filesystem that does
> not support mmap-writing. Others are jffs2, afs, 9p.
>
>  

I dont know if there is anything wrong with our mmap() solution.
But I am sure that simply removing these lines

.aio_read = generic_file_aio_read,
.aio_write = generic_file_aio_write,

from the dazukofs_main_fops will be sufficient to avoid the bug
http://lists.gnu.org/archive/html/dazuko-devel/2009-10/msg00002.html
for the reasons I gave in my former post.
IMO this bug has nothing to do with mmap().

Regards,
Lino Sanfilippo







Geschäftsführender Gesellschafter: Tjark Auerbach
Sitz der Gesellschaft: Tettnang
Handelsregister: Amtsgericht Ulm, HRB 630992
ALLGEMEINE GESCHÄFTSBEDINGUNGEN
Es gelten unsere Allgemeinen Geschäftsbedingungen
(AGB). Sie finden sie in der jeweils gültigen Fassung
im Internet unter http://www.avira.de/agb
***************************************************


_______________________________________________
Dazuko-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/dazuko-devel