On Wed, Feb 22, 2012 at 08:17:15AM -0600, David Young wrote:
> On Wed, Feb 22, 2012 at 01:42:45PM +0100, Manuel Wiesinger wrote:
> > *)
> > What is it good for? The only practical use I can imagine are
> > backups on thin clients, which operate without a hard disk. But this
> > is clearly far-
On Wed, Feb 22, 2012 at 01:42:45PM +0100, Manuel Wiesinger wrote:
> *)
> What is it good for? The only practical use I can imagine are
> backups on thin clients, which operate without a hard disk. But this
> is clearly far-fetched, in my eyes.
It's good for writing checkpoints of a tmpfs to non-vo
Another possible thing to do (instead) would be to look at Coda, and
consider something like porting Coda to use FUSE instead of a homegrown
(pre-FUSE, to be fair) kernel module. A bigger challenge is to separate
the write-back caching from the upstream server protocol, so that one
could use some
Note that we already have file system snapshots for ffs file systems,
see fss(4). They are used for backup purposes (atomically create a snapshot,
while the file system is busy, then backup the now quiet snapshot) - among
others.
> *)
> What is it good for? The only practical use I can imagine are
Hi folks,
when stumbling around in the wiki for interesting topics for my bachelor
thesis I found this entry:
http://wiki.netbsd.org/projects/project/tmpfs-snapshot
I consider to work on that this summer.
What I've done so far:
*) spoke to a lecturer who is very interested in this topic and
On Mon, Feb 20, 2012 at 09:13:42PM +0100, Stephan wrote:
> thanks for that clarification. Do you have an idea what the best
> solution for this issue would be? Is there a way to make sure the name
> cache contains the appropriate information if getcwd() is not an
> alternative?
>
> I know of
On Tue, Feb 21, 2012 at 04:06:02PM -0500, Mouse wrote:
> >> I have a question regarding the vnode_to_path() function [...]
>
> > The problem is that it works if and only if [...].
>
> That's the immediate pragmatic problem.
>
> More serious, I think, is that it exhibits a much more fundam
