Antti Kantee wrote:
> Not sure, but per a quick examination it looks like nfs wants to save
> the error for the next caller. As long as puffs is synchronous, it
> won't be an issue. Notably, though, a puffs file server might like to
> be asynchronous in handling a write and report an error lat
On 29/10/14 23:33, Emmanuel Dreyfus wrote:
Antti Kantee wrote:
That comment is close to 10 years old. If you haven't, start by
checking that it still applies and perhaps do a quick check to see what
goes wrong (I don't remember exactly, some sort of kernel panic I think)
and if it can be fixe
Antti Kantee wrote:
> That comment is close to 10 years old. If you haven't, start by
> checking that it still applies and perhaps do a quick check to see what
> goes wrong (I don't remember exactly, some sort of kernel panic I think)
> and if it can be fixed.
I just tried removing this if (er
Date: Wed, 29 Oct 2014 00:11:41 +
From: Emmanuel Dreyfus
Let me rephrase: I call close(), get a error because of a failed
asynchronous write. The file is not closed, right? Now if I call
close again, what should happen? Success?
Nope. close(2) guarantees the file descriptor
On 29/10/14 00:11, Emmanuel Dreyfus wrote:
On Tue, Oct 28, 2014 at 06:07:29PM +0100, J. Hannken-Illjes wrote:
Confused. If write and/or fsync are synchronous (VOP_PUTPAGES with
flag PGO_SYNCIO) no write error will be forgotten.
puffs_vnop_stratgy() contains this:
/*
Thor Lancelot Simon wrote:
> > Let me rephrase: I call close(), get a error because of a failed
> > asynchronous write. The file is not closed, right? Now if I call
>
> Wrong. It's still closed.
Thank you for that helpful explanation.
Another concern: a file may be open by multiple processes.
On Wed, Oct 29, 2014 at 12:11:41AM +, Emmanuel Dreyfus wrote:
> On Tue, Oct 28, 2014 at 06:07:29PM +0100, J. Hannken-Illjes wrote:
> > Confused. If write and/or fsync are synchronous (VOP_PUTPAGES with
> > flag PGO_SYNCIO) no write error will be forgotten.
>
> puffs_vnop_stratgy() contains t
On Tue, Oct 28, 2014 at 06:07:29PM +0100, J. Hannken-Illjes wrote:
> Confused. If write and/or fsync are synchronous (VOP_PUTPAGES with
> flag PGO_SYNCIO) no write error will be forgotten.
puffs_vnop_stratgy() contains this:
/*
* : wrong, but kernel can't
On 28 Oct 2014, at 15:43, Emmanuel Dreyfus wrote:
> On Tue, Oct 28, 2014 at 02:52:36PM +0100, J. Hannken-Illjes wrote:
>> NFS allows them and therefore VOP_CLOSE is the last chance to report
>> write errors back to the application.
>
> The situation is a bit different: write and fsync call VOP_P
On Tue, Oct 28, 2014 at 02:52:36PM +0100, J. Hannken-Illjes wrote:
> NFS allows them and therefore VOP_CLOSE is the last chance to report
> write errors back to the application.
The situation is a bit different: write and fsync call VOP_PUTPAGE
which calls VOP_STRATEGY and forgets about the write
On 28 Oct 2014, at 14:37, Emmanuel Dreyfus wrote:
> On Sun, Oct 26, 2014 at 09:21:13AM +0100, J. Hannken-Illjes wrote:
>> - You should recover the error in puffs_vnop_close() too.
>
> Should I? puffs_vnop_close() does not cause VOP_STRATEGY to be
> called, it only send a message to the filesyste
On Sun, Oct 26, 2014 at 09:21:13AM +0100, J. Hannken-Illjes wrote:
> - You should recover the error in puffs_vnop_close() too.
Should I? puffs_vnop_close() does not cause VOP_STRATEGY to be
called, it only send a message to the filesystem: If I recover
the VOP_STRATEGy error there I will steall i
On 26 Oct 2014, at 19:13, Emmanuel Dreyfus wrote:
> J. Hannken-Illjes wrote:
>
>> Since it was last incremented at Rev. 1.72 many messages got additional
>> fields so the version should be incremented independent of your change.
>
> What messages are you referring to? Each time I added somethi
J. Hannken-Illjes wrote:
> Since it was last incremented at Rev. 1.72 many messages got additional
> fields so the version should be incremented independent of your change.
What messages are you referring to? Each time I added something it was
meants to be backward compatible.
--
Emmanuel Dre
On 26 Oct 2014, at 17:55, Emmanuel Dreyfus wrote:
> J. Hannken-Illjes wrote:
>
>> What happens when libpuffs receives an unknown message (fallocate in
>> this case)?
>
> The filesystem using libpuffs tells the kernel what operations should be
> sent to userland when it calls puffs_init(). It c
J. Hannken-Illjes wrote:
> What happens when libpuffs receives an unknown message (fallocate in
> this case)?
The filesystem using libpuffs tells the kernel what operations should be
sent to userland when it calls puffs_init(). It can be done
- by setting the list of wanted operation, in which
On 26 Oct 2014, at 08:46, Emmanuel Dreyfus wrote:
> J. Hannken-Illjes wrote:
>
>> - Increment PUFFSVERSION.
>
> When is it really required? Without incrementing it, a newer kernel
> works with an older libpuffs, but if I increase it I get an error about
> version mismatch.
What happens when l
J. Hannken-Illjes wrote:
> - Increment PUFFSVERSION.
When is it really required? Without incrementing it, a newer kernel
works with an older libpuffs, but if I increase it I get an error about
version mismatch.
> - You should recover the error in puffs_vnop_close() too.
Right.
> - Are you sur
On 26 Oct 2014, at 03:52, Emmanuel Dreyfus wrote:
> Chuck Silvers wrote:
>
>> but more fundamentally, since puffs code cannot prevent changes to the file
>> in the underlying fs (ie. changes that don't go through puffs), any
>> preallocation done by puffs can be undone before it does any good.
Chuck Silvers wrote:
> but more fundamentally, since puffs code cannot prevent changes to the file
> in the underlying fs (ie. changes that don't go through puffs), any
> preallocation done by puffs can be undone before it does any good.
> the puffs code just needs to be fixed to handle such ENOS
Chuck Silvers wrote:
> but more fundamentally, since puffs code cannot prevent changes to the file
> in the underlying fs (ie. changes that don't go through puffs), any
> preallocation done by puffs can be undone before it does any good.
> the puffs code just needs to be fixed to handle such ENOS
On Sat, Oct 25, 2014 at 09:48:49AM +0200, J. Hannken-Illjes wrote:
> On 25 Oct 2014, at 06:39, Emmanuel Dreyfus wrote:
>
> > Summary: when writing to a PUFFS filesystem through page cache, we do
> > not know if backend storage is really available. If it is not, cache
> > flush may get EDQUOT or E
On 25 Oct 2014, at 06:39, Emmanuel Dreyfus wrote:
> Summary: when writing to a PUFFS filesystem through page cache, we do
> not know if backend storage is really available. If it is not, cache
> flush may get EDQUOT or ENOSPC and the process cannot terminate (it gets
> stuck in DE state).
>
> Pr
Summary: when writing to a PUFFS filesystem through page cache, we do
not know if backend storage is really available. If it is not, cache
flush may get EDQUOT or ENOSPC and the process cannot terminate (it gets
stuck in DE state).
Proposed solution: detect that a write may not have backend storag
24 matches
Mail list logo
