Re: [RFC 0/7] [RFC] cramfs: fake write support

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Arnd Bergmann <arnd@...>
Cc: Jamie Lokier <jamie@...>, Phillip Lougher <phillip@...>, David Newall <davidn@...>, <linux-fsdevel@...>, <linux-kernel@...>, <hch@...>
Date: Monday, June 2, 2008 - 6:36 am

Arnd Bergmann:

I will try explain individually.
Here are what I implemented in AUFS.
Any comments are welcome.

Aufs has three levels of detecting the direct-access to the lower
(branch) filesystems (ie. bypassing aufs). I guess the most strict level
is a good answer for your question. It is based on the inotify
feature. Aufs sets inotify-watch to every accessed directories on lower
fs. During those inodes are cached, aufs receives the inotify event for
thier children/files and marks the aufs data for the file is
obsoleted. When the file is accessed later, aufs retrives the latest
inode (or dentry) again.
The inotify-watch will be removed when the aufs dir inode is discarded
from cache.



Aufs has its own dentry and inode object as normal fs has. And they have
pointers to the corresponding ones on the lower fs. If you make a union
from two real filesystems, then aufs inode will have (at most) two
pointers as its private data.
Do you mean having pointers is a duplicataion?



Yes, that's right.
Aufs reserves ".wh." as a whiteout prefix, and prohibits users to handle
such filename inside aufs. It might be a problem as you wrote, but users
can create/remove them directly on the lower fs and I have never
received request about this reserved prefix.



Aufs readdir operation consumes memory, but it is not stack. If it was
implemented as a recursive function, it might cause the stack
overflow. But actually it is a loop.
The memory is used for stroing entry names and eliminating whiteout-ed
ones, and the result will be cached for a specified time. So the memory
(other than stack) will be consumed.



Probably you are right. Initially aufs had only one policy to select the
writable branch. But several users requested another policy such as
round-robin or most-free-spece, and aufs has implemented them.
I don't guess uers will be confused by these policies. While I tried it
should be simple, I guess some people will say it is complex.


Junjiro Okajima


--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [RFC 0/7] [RFC] cramfs: fake write support, Phillip Lougher, (Sat May 31, 11:19 pm)
Re: [RFC 0/7] [RFC] cramfs: fake write support, David Newall, (Sat May 31, 2:56 pm)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Arnd Bergmann, (Sat May 31, 4:40 pm)
Re: [RFC 0/7] [RFC] cramfs: fake write support, David Newall, (Sun Jun 1, 2:02 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Jan Engelhardt, (Sun Jun 1, 5:11 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Phillip Lougher, (Sat May 31, 11:54 pm)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Jamie Lokier, (Sun Jun 1, 8:28 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Arnd Bergmann, (Sun Jun 1, 5:49 pm)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Arnd Bergmann, (Mon Jun 2, 3:12 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support , Erez Zadok, (Mon Jun 2, 11:35 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support , , (Mon Jun 2, 6:36 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Arnd Bergmann, (Mon Jun 2, 7:15 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Evgeniy Polyakov, (Mon Jun 2, 10:54 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Arnd Bergmann, (Mon Jun 2, 1:42 pm)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Arnd Bergmann, (Mon Jun 2, 10:13 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Arnd Bergmann, (Mon Jun 2, 11:01 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support , Erez Zadok, (Mon Jun 2, 12:37 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support , Jan Engelhardt, (Mon Jun 2, 3:17 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Bharata B Rao, (Mon Jun 2, 2:07 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support , Erez Zadok, (Sun Jun 1, 11:51 pm)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Jamie Lokier, (Mon Jun 2, 7:07 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support , Erez Zadok, (Sun Jun 1, 11:25 pm)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Arnd Bergmann, (Mon Jun 2, 3:51 am)
Re: [RFC 0/7] [RFC] cramfs: fake write support , Erez Zadok, (Mon Jun 2, 2:13 pm)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Phillip Lougher, (Mon Jun 2, 10:02 pm)
Re: [RFC 0/7] [RFC] cramfs: fake write support, Arnd Bergmann, (Sun Jun 1, 4:52 am)