[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fuse-devel
Subject:    Re: [fuse-devel] Locking a filesystem for reorganization
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2011-09-29 12:20:35
Message-ID: 20110929122035.GA8182 () space ! twc ! de
[Download RAW message or body]

   Hi!

Yes, that sounds like a good idea. Its still somewhat more work than with a
complete lock, as even if the data is only read from the filesystem, I have to
ensure that during read the filesystem is in a consistent state. So I'll have
to communicate with the fuse process to ensure that this constraint is not
violated.

Well, anyway, I'm now working on an implementation which allows reading during
commit.

   Cu... Stefan

On Thu, Sep 29, 2011 at 12:02:59AM +0200, Mathias Panzenb?ck wrote:
> Instead of completely locking, could you make it read only?
> 
> On 09/28/2011 11:00 PM, Stefan Westerfeld wrote:
> >     Hi!
> >
> > I'm writing a filesystem with fuse that should store content hashes combined
> > with history as representation of the files. So normally you can write new
> > files and the contents are just stored. But once you run an external program,
> > like
> >
> > $ bfsync2 commit
> >
> > I need to transform the file contents into hashes and update the history. I
> > don't want the fuse filesystem to interfere with the reorganization.
> >
> > My first approach was to let the external program (bfsync2) write a special
> > file called .bfsync/lock to the FUSE filesystem and write its own pid into the
> > lock file. Then I added code into every bfsync_open/bfsync_read/...  function
> > to simply wait for the pid to terminate and block.
> >
> > However, I've seen that this often causes problems: for instance under KDE4 (if
> > I understood this correctly), the terminal emulator konsole tries to magically
> > tell the user the working directory of the running process. Since the FUSE
> > filesystem is locked during bfsync2 commit, konsole blocks (since all bfsync
> > filesystem operations block). Since konsole blocks, the terminal output of
> > bfsync2 commit isn't read anymore, so the commit also blocks. Deadlock. Only
> > killing the bfsync2 commit process helps.
> >
> > Any suggestions of how to do this properly?
> >
> >     Cu... Stefan
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> fuse-devel mailing list
> fuse-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fuse-devel

-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
fuse-devel mailing list
fuse-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel
[prev in list] [next in list] [prev in thread] [next in thread]