On 3 Mar 2007, at 22:45, Arnd Bergmann wrote:
On Friday 02 March 2007 00:38:19 Christoph Hellwig wrote:
Forgive me if I haven't put enough thought into it, but would it be
useful to create a generic_fallocate() that writes zeroed pages
for any
non-existent pages in the range? I don't know
On Sunday 04 March 2007, Anton Altaparmakov wrote:
A generic_fallocate makes sense to me iff we can do it in the kernel
more significantly more efficiently than in glibc, e.g. by using only
a single page in page cache instead of one for each page to be
preallocated.
If glibc is
Anton Altaparmakov wrote:
And that is it. No zeroing needs to happen at all because we
have not updated the initialized size of the inode!
When you do it like this, who can the kernel/filesystem *guarantee* that
when the data is written there actually is room on the harddrive?
What you
On 5 Mar 2007, at 00:16, Jörn Engel wrote:
On Sun, 4 March 2007 14:38:13 -0800, Ulrich Drepper wrote:
When you do it like this, who can the kernel/filesystem
*guarantee* that
when the data is written there actually is room on the harddrive?
What you described seems like using
On 5 Mar 2007, at 00:32, Anton Altaparmakov wrote:
On 5 Mar 2007, at 00:16, Jörn Engel wrote:
On Sun, 4 March 2007 14:38:13 -0800, Ulrich Drepper wrote:
When you do it like this, who can the kernel/filesystem
*guarantee* that
when the data is written there actually is room on the
Signed-off-by: Josef 'Jeff' Sipek [EMAIL PROTECTED]
---
fs/unionfs/dirfops.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/unionfs/dirfops.c b/fs/unionfs/dirfops.c
index 2b77fa9..8f568c7 100644
--- a/fs/unionfs/dirfops.c
+++ b/fs/unionfs/dirfops.c
@@ -135,15
1) No need to lock the inode - lockdep was complaining about potential
circular dependency
2) No need to use temporary variable for iunique() inode number
3) Removed unneeded comment
Signed-off-by: Josef 'Jeff' Sipek [EMAIL PROTECTED]
---
fs/unionfs/main.c | 11 ++-
1 files changed,
Signed-off-by: Josef 'Jeff' Sipek [EMAIL PROTECTED]
---
fs/unionfs/super.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 176cfb6..571b589 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -320,9 +320,8 @@ static
From: Erez Zadok [EMAIL PROTECTED]
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
Signed-off-by: Josef 'Jeff' Sipek [EMAIL PROTECTED]
---
fs/unionfs/commonfops.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
Grabbing the UNIONFS_D(dentry)-lock is completely unnecessary and there are
no other references; we are about to free the object anyway. Additionally,
grabbing the mutex produces warning when the slab object is reused - as it
was freed while there still was a reference to it.
Signed-off-by: Erez
From: Erez Zadok [EMAIL PROTECTED]
Signed-off-by: Erez Zadok [EMAIL PROTECTED]
Signed-off-by: Josef 'Jeff' Sipek [EMAIL PROTECTED]
---
fs/unionfs/lookup.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/fs/unionfs/lookup.c b/fs/unionfs/lookup.c
index
On Sun, 4 March 2007 14:38:13 -0800, Ulrich Drepper wrote:
When you do it like this, who can the kernel/filesystem *guarantee* that
when the data is written there actually is room on the harddrive?
What you described seems like using truncate/ftruncate to increase the
file's size. That is
On Sun, Mar 04, 2007 at 08:11:17PM +, Anton Altaparmakov wrote:
glibc cannot ever be smart enough because a file system driver will
always know better and be able to do things in a much more optimized
way.
Please read the thread again. That is not what anyone proposed.
The issues
13 matches
Mail list logo
