>The chance of an accidental
>collision is infinitesimally small. For a set of
>
> 100 files: 0.03%
> 1,000,000 files: 0.03%
Hey, if you're going to use a mathematical term, use it right. :-)
.03% isn't infinitesimal. It's just insignificant. And I think
infini
>Statement 1:
>If two files have identical st_dev and st_ino, they MUST be hardlinks of
>each other/the same file.
>
>Statement 2:
>If two "files" are a hardlink of each other, they MUST be detectable
>(for example by having the same st_dev/st_ino)
>
>I personally consider statement 1 a mandatory r
Bryan Henderson wrote:
>
>>Adding a vfs call to check for file equivalence seems like a good idea to
me.
>
>That would be only barely useful. It would let 'diff' say, "those are
>both the same file," but wouldn't be useful for something trying to
>duplicate a filesystem (e.g. a backup program)
On Thu, 28 Dec 2006 13:53:08 +0530
Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
> This patchset implements changes to make filesystem AIO read
> and write asynchronous for the non O_DIRECT case.
I did s/lock_page_slow/lock_page_blocking/g then merged all these
into -mm, thanks.
-
To unsubscrib
On Thu, 28 Dec 2006 14:09:00 +0530
Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
> +#define init_wait_bit_key(waitbit, word, bit)
> \
> + do {\
> + (waitbit)->key.flags = word;
Mikulas Patocka wrote:
>
>>> This sounds like a bug to me. It seems like we should have a one to one
>>> correspondence of filehandle -> inode. In what situations would this not be
>>> the
>>> case?
>>
>> Well, the NFS protocol allows that [see rfc1813, p. 21: "If two file handles
>> from
>> the
> >> It seems like the posix idea of unique doesn't
> >> hold water for modern file systems
> >
> > are you really sure?
>
> Well Jan's example was of Coda that uses 128-bit internal file ids.
>
> > and if so, why don't we fix *THAT* instead
>
> Hmm, sometimes you can't fix the world, especia
> If it's important to know that two names refer to the same file in a
> remote filesystem, I don't see any way around adding a new concept of file
> identifier to the protocol.
actually there are 2 separate issues at hand, and this thread sort of
confuses them into one:
Statement 1:
If two fi
On Thu, 2006-12-28 at 09:58 -0800, Bryan Henderson wrote:
> >Adding a vfs call to check for file equivalence seems like a good idea to
> me.
>
> That would be only barely useful. It would let 'diff' say, "those are
> both the same file," but wouldn't be useful for something trying to
> duplica
This sounds like a bug to me. It seems like we should have a one to one
correspondence of filehandle -> inode. In what situations would this not be the
case?
Well, the NFS protocol allows that [see rfc1813, p. 21: "If two file handles
from
the same server are equal, they must refer to the same
>> Well, the NFS protocol allows that [see rfc1813, p. 21: "If two file
handles from
>> the same server are equal, they must refer to the same file, but if
they are not
>> equal, no conclusions can be drawn."]
>>
>Interesting. That does seem to break the method of st_dev/st_ino for
finding
>ha
On Thu, 28 Dec 2006, Arjan van de Ven wrote:
It seems like the posix idea of unique doesn't
hold water for modern file systems
are you really sure?
and if so, why don't we fix *THAT* instead, rather than adding racy
syscalls and such that just can't really be used right...
Why don't you r
>Adding a vfs call to check for file equivalence seems like a good idea to
me.
That would be only barely useful. It would let 'diff' say, "those are
both the same file," but wouldn't be useful for something trying to
duplicate a filesystem (e.g. a backup program). Such a program can't do
the
On Thu, 28 Dec 2006 17:22:07 +0100 (MET) Jan Engelhardt wrote:
>
> On Dec 28 2006 11:57, Christoph Hellwig wrote:
> >
> >> +
> >> + if ((error = __lock_page(page, current->io_wait))) {
> >> + goto readpage_error;
> >> + }
> >
> >This should be
> >
> >
On Dec 28 2006 10:54, Jeff Layton wrote:
>
> Sorry, I should qualify that statement. A lot of filesystems don't have
> permanent i_ino values (mostly pseudo filesystems -- pipefs, sockfs, /proc
> stuff, etc). For those, the idea is to try to make sure we use 32 bit values
> for them and to ensure
On Dec 28 2006 11:57, Christoph Hellwig wrote:
>
>> +
>> +if ((error = __lock_page(page, current->io_wait))) {
>> +goto readpage_error;
>> +}
>
>This should be
>
> error = __lock_page(page, current->io_wait);
> if (error)
>
Benny Halevy wrote:
Jeff Layton wrote:
Benny Halevy wrote:
It seems like the posix idea of unique doesn't
hold water for modern file systems and that creates real problems for
backup apps which rely on that to detect hard links.
Why not? Granted, many of the filesystems in the Linux kernel do
Arjan van de Ven wrote:
>> It seems like the posix idea of unique doesn't
>> hold water for modern file systems
>
> are you really sure?
Well Jan's example was of Coda that uses 128-bit internal file ids.
> and if so, why don't we fix *THAT* instead
Hmm, sometimes you can't fix the world, esp
On Thu, Dec 28, 2006 at 11:57:47AM +, Christoph Hellwig wrote:
> > + if (in_aio()) {
> > + /* Avoid repeat readahead */
> > + if (kiocbTryRestart(io_wait_to_kiocb(current->io_wait)))
> > + next_index = last_index;
> > + }
>
> Every place we use kiocbTr
Jeff Layton wrote:
> Benny Halevy wrote:
>> It seems like the posix idea of unique doesn't
>> hold water for modern file systems and that creates real problems for
>> backup apps which rely on that to detect hard links.
>>
>
> Why not? Granted, many of the filesystems in the Linux kernel don't e
On Thu, Dec 28, 2006 at 11:55:10AM +, Christoph Hellwig wrote:
> On Thu, Dec 28, 2006 at 02:11:49PM +0530, Suparna Bhattacharya wrote:
> > -extern void FASTCALL(lock_page_slow(struct page *page));
> > +extern int FASTCALL(__lock_page_slow(struct page *page, wait_queue_t
> > *wait));
> > exter
> Pluse possible naming updates discussed in the last mail. Also do we
> really need to pass current->io_wait here? Isn't the waitqueue in
> the kiocb always guaranteed to be the same? Now that all pagecache
> I/O goes through the ->aio_read/->aio_write routines I'd prefer to
> get rid of the ta
Benny Halevy wrote:
It seems like the posix idea of unique doesn't
hold water for modern file systems and that creates real problems for
backup apps which rely on that to detect hard links.
Why not? Granted, many of the filesystems in the Linux kernel don't enforce that
they have unique st_
Hi,
I am working on a testing framework for file systems focusing on
repair and recovery areas. Right now, I have been timing fsck and
trying to determine the effectiveness of fsck. The idea that I have is
below.
In abstract terms, I create a file system (ideal state), corrupt it,
run fsck on it
> + if (in_aio()) {
> + /* Avoid repeat readahead */
> + if (kiocbTryRestart(io_wait_to_kiocb(current->io_wait)))
> + next_index = last_index;
> + }
Every place we use kiocbTryRestart in this and the next patch it's in
this from, so we should add
On Thu, Dec 28, 2006 at 02:11:49PM +0530, Suparna Bhattacharya wrote:
> -extern void FASTCALL(lock_page_slow(struct page *page));
> +extern int FASTCALL(__lock_page_slow(struct page *page, wait_queue_t *wait));
> extern void FASTCALL(__lock_page_nosync(struct page *page));
> extern void FASTCALL(
[ I'm only subscribed to linux-fsdevel@ from above Cc list, please keep this
list in Cc: for AIO related stuff. ]
On Wed, Dec 27, 2006 at 04:25:30PM +, Christoph Hellwig ([EMAIL PROTECTED])
wrote:
> (1) note that there is another problem with the current kevent interface,
> and that is
> It seems like the posix idea of unique doesn't
> hold water for modern file systems
are you really sure?
and if so, why don't we fix *THAT* instead, rather than adding racy
syscalls and such that just can't really be used right...
--
if you want to mail me at work (you don't), use arjan (a
Mikulas Patocka wrote:
>>> If user (or script) doesn't specify that flag, it doesn't help. I think
>>> the best solution for these filesystems would be either to add new syscall
>>> int is_hardlink(char *filename1, char *filename2)
>>> (but I know adding syscall bloat may be objectionable)
>> i
* Suparna Bhattacharya <[EMAIL PROTECTED]> wrote:
> The following is a sampling of comparative aio-stress results with the
> patches (each run starts with uncached files):
>
> -
>
> aio-stress throughput comparisons (in
Sorry this should have read [PATCH 1/8] instead of [PATCH 1/6]
Regards
Suparna
--
Suparna Bhattacharya ([EMAIL PROTECTED])
Linux Technology Center
IBM Software Lab, India
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Mor
AIO support for O_SYNC buffered writes, built over O_SYNC-speedup.
It uses the tagged radix tree lookups to writeout just the pages
pertaining to this request, and retries instead of blocking
for writeback to complete on the same range. All the writeout is
issued at the time of io submission, and
Converts the wait for page to become uptodate (lock page)
after readahead/readpage (in do_generic_mapping_read) to a retry
exit, to make buffered filesystem AIO reads actually synchronous.
The patch avoids exclusive wakeups with AIO, a problem originally
spotted by Chris Mason, though the reasoni
Define low-level page wait and lock page routines which take a
wait queue entry pointer as an additional parameter and
return status (which may be non-zero when the wait queue
parameter signifies an asynchronous wait, typically during
AIO).
Synchronous IO waits become a special case where the wai
Enable wait bit based filtered wakeups to work for AIO.
Replaces the wait queue entry in the kiocb with a wait bit
structure, to allow enough space for the wait bit key.
This adds an extra level of indirection in references to the
wait queue entry in the iocb. Also, an extra check had to be
added
Allocates space for the default io wait queue entry (actually a wait
bit entry) in the task struct. Doing so simplifies the patches
for AIO wait page allowing for cleaner and more efficient
implementation, at the cost of 28 additional bytes in task struct
vs allocation on demand on-stack.
Signe
init_wait_bit_key() initializes the key field in an already
allocated wait bit structure, useful for async wait bit support.
Also separate out the wait bit test to a common routine which
can be used by different kinds of wakeup callbacks.
Signed-off-by: Suparna Bhattacharya <[EMAIL PROTECTED]>
A
In order to allow for interruptible and asynchronous versions of
lock_page in conjunction with the wait_on_bit changes, we need to
define low-level lock page routines which take an additional
argument, i.e a wait queue entry and may return non-zero status,
e.g -EINTR, -EIOCBRETRY, -EWOULDBLOCK etc
Add a wait queue parameter to the action routine called by
__wait_on_bit to allow it to determine whether to block or
not.
Signed-off-by: Suparna Bhattacharya <[EMAIL PROTECTED]>
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
---
linux-2.6.20-rc1-root/fs/buffer.c |2 +-
linux-2
Currently native linux AIO is properly supported (in the sense of
actually being asynchronous) only for files opened with O_DIRECT.
While this suffices for a major (and most visible) user of AIO, i.e. databases,
other types of users like Samba require AIO support for regular file IO.
Also, for gli
40 matches
Mail list logo
