If generic_file_direct_write() has fail (ENOSPC condition) inside
__generic_file_aio_write_nolock() it may have instantiated a few blocks outside
i_size in case of non blockdev files. At least ext2, ext3 and reiserfs interpret
i_size and biggest block difference as error. Later fsck will complain
Where are several places where the same code used for iovec checks.
This patch just move this code to separate helper function, and replace
duplicated code with it. IMHO it is better because these are checks that
we want for all filesystems/drivers that use vectored I/O.
Signed-off-by: Dmitriy Mo
David Chinner wrote:
Generic page_mkwrite functionality.
Filesystems that make use of the VM ->page_mkwrite() callout will generally use
the same core code to implement it. There are several tricky truncate-related
issues that we need to deal with here as we cannot take the i_mutex as we
normall
On Mar 18 2007 14:13, Matthew Wilcox wrote:
>
>Equally, if one has one's ogg collection stored on said NFS server, the
>ogg player will be in uninterruptible sleep while holding the sound device
>open, preventing other applications from making sounds.
Only if you have
- a card with no hardware
Implement ->page_mkwrite in XFS.
Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]>
---
fs/xfs/linux-2.6/xfs_file.c | 16
1 file changed, 16 insertions(+)
Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c
===
--- 2.
Generic page_mkwrite functionality.
Filesystems that make use of the VM ->page_mkwrite() callout will generally use
the same core code to implement it. There are several tricky truncate-related
issues that we need to deal with here as we cannot take the i_mutex as we
normally would for these path
On 3/18/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
On Fri, 2007-03-16 at 23:06 -0500, Mike Snitzer wrote:
> I'm interested in understanding the state of Linux with regard to
> _really_ forcing a filesystem to unmount.
>
> There is a (stale) project at OSDL that has various implementations:
>
On Sun, Mar 18, 2007 at 08:16:19PM +0100, Arjan van de Ven wrote:
> the problem with the people who say they want forced umount is.. that
> most of the time they either want
> 1) get rid of the namespace entry
> or
> 2) want to stop any and all IO to a certain device/partition
There is a third co
On Fri, 2007-03-16 at 23:06 -0500, Mike Snitzer wrote:
> I'm interested in understanding the state of Linux with regard to
> _really_ forcing a filesystem to unmount.
>
> There is a (stale) project at OSDL that has various implementations:
> http://developer.osdl.org/dev/fumount/
the problem wit
I'm looking for pointers to places to look (and especially documentation,
if it exists) for how to directly access the VFS and its superblocks, and
how to create a superblock private to my own structure.
The first part is basically this: I want to be able to create syscalls
parallel to the nor
10 matches
Mail list logo