Christoph Hellwig wrote:
On Thu, Dec 28, 2006 at 08:17:17PM +0530, Suparna Bhattacharya wrote:
I am really bad with names :( I tried using the _wq suffixes earlier and
that seemed confusing to some, but if no one else objects I'm happy to use
that. I thought aio_lock_page() might be misleading
Suparna Bhattacharya wrote:
On Thu, Jan 04, 2007 at 04:51:58PM +1100, Nick Piggin wrote:
So long as AIO threads do the same, there would be no problem (plugging
is optional, of course).
Yup, the AIO threads run the same code as for regular IO, i.e in the rare
situations where they actually
On Thu, Jan 04, 2007 at 04:51:58PM +1100, Nick Piggin wrote:
> Suparna Bhattacharya wrote:
> >On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew Morton wrote:
>
> >>Plus Jens's unplugging changes add more reliance upon context inside
> >>*current, for the plugging and unplugging operations. I expec
Suparna Bhattacharya wrote:
On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew Morton wrote:
Plus Jens's unplugging changes add more reliance upon context inside
*current, for the plugging and unplugging operations. I expect that the
fsaio patches will need to be aware of the protocol which tho
On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew Morton wrote:
> 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.
>
> Unfortunately the unpl
On Wed, 2007-01-03 at 14:35 +0200, Benny Halevy wrote:
> Believe it or not, but server companies like Panasas try to follow the
> standard
> when designing and implementing their products while relying on client vendors
> to do the same.
I personally have never given a rats arse about "standards"
On Thu, Jan 04, 2007 at 12:43:20AM +0100, Mikulas Patocka wrote:
> On Wed, 3 Jan 2007, Frank van Maarseveen wrote:
> >Currently, large file support is already necessary to handle dvd and
> >video. It's also useful for images for virtualization. So the failing
> >stat()
> >calls should already be a
Eric Sandeen wrote:
> Take 2... all in one file. I suppose I really did know better than
> to create that new header. ;-)
>
> Better?
Ugh, sorry for the internal/external cross-post, that was supposed to be
to LKML... not enough sleep last night. Please adjust replies
accordingly. :(
-Eric
On Wed, 3 Jan 2007, Frank van Maarseveen wrote:
On Wed, Jan 03, 2007 at 01:09:41PM -0800, Bryan Henderson wrote:
On any decent filesystem st_ino should uniquely identify an object and
reliably provide hardlink information. The UNIX world has relied upon
this
for decades. A filesystem with st_
Take 2... all in one file. I suppose I really did know better than
to create that new header. ;-)
Better?
---
CVE-2006-5753 is for a case where an inode can be marked bad, switching
the ops to bad_inode_ops, which are all connected as:
static int return_EIO(void)
{
return -EIO;
}
#
Hi Eric,
On Wed, 03 Jan 2007 12:42:47 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote:
>
> So here's the first stab at fixing it. I'm sure there are style points
> to be hashed out. Putting all the functions as static inlines in a header
> was just to avoid hundreds of lines of simple function decl
Stephen Rothwell wrote:
> Hi Eric,
>
> On Wed, 03 Jan 2007 12:42:47 -0600 Eric Sandeen <[EMAIL PROTECTED]> wrote:
>> So here's the first stab at fixing it. I'm sure there are style points
>> to be hashed out. Putting all the functions as static inlines in a header
>> was just to avoid hundreds o
Hi!
> >Sure it is. Numerous popular POSIX filesystems do that. There is a lot of
> >inode number space in 64 bit (of course it is a matter of time for it to
> >jump to 128 bit and more)
>
> If the filesystem was designed by someone not from Unix world (FAT, SMB,
> ...), then not. And users still
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.
Unfortunately the unplugging changes in Jen's block tree have trashed these
patches to a degree tha
On Wed, Jan 03, 2007 at 01:09:41PM -0800, Bryan Henderson wrote:
> >On any decent filesystem st_ino should uniquely identify an object and
> >reliably provide hardlink information. The UNIX world has relied upon
> this
> >for decades. A filesystem with st_ino collisions without being hardlinked
>
>On any decent filesystem st_ino should uniquely identify an object and
>reliably provide hardlink information. The UNIX world has relied upon
this
>for decades. A filesystem with st_ino collisions without being hardlinked
>(or the other way around) needs a fix.
But for at least the last of those
On Wed, Jan 03, 2007 at 08:31:32PM +0100, Mikulas Patocka wrote:
> I didn't hardlink directories, I just patched stat, lstat and fstat to
> always return st_ino == 0 --- and I've seen those failures. These
> failures
> are going to happen on non-POSIX filesystems in real world too,
I didn't hardlink directories, I just patched stat, lstat and fstat to
always return st_ino == 0 --- and I've seen those failures. These failures
are going to happen on non-POSIX filesystems in real world too, very
rarely.
I don't want to spoil your day but testing with st_ino==0 is a bad choice
On Wed, Jan 03, 2007 at 08:17:34PM +0100, Mikulas Patocka wrote:
>
> On Wed, 3 Jan 2007, Frank van Maarseveen wrote:
>
> >On Tue, Jan 02, 2007 at 01:04:06AM +0100, Mikulas Patocka wrote:
> >>
> >>I didn't hardlink directories, I just patched stat, lstat and fstat to
> >>always return st_ino == 0
On Wed, 3 Jan 2007, Frank van Maarseveen wrote:
On Tue, Jan 02, 2007 at 01:04:06AM +0100, Mikulas Patocka wrote:
I didn't hardlink directories, I just patched stat, lstat and fstat to
always return st_ino == 0 --- and I've seen those failures. These failures
are going to happen on non-POSIX
On Tue, Jan 02, 2007 at 01:04:06AM +0100, Mikulas Patocka wrote:
>
> I didn't hardlink directories, I just patched stat, lstat and fstat to
> always return st_ino == 0 --- and I've seen those failures. These failures
> are going to happen on non-POSIX filesystems in real world too, very
> rarel
On Wed, 3 Jan 2007, Miklos Szeredi wrote:
High probability is all you have. Cosmic radiation hitting your
computer will more likly cause problems, than colliding 64bit inode
numbers ;)
Some of us have machines designed to cope with cosmic rays, and would be
unimpressed with a decrease in re
CVE-2006-5753 is for a case where an inode can be marked bad, switching
the ops to bad_inode_ops, which are all connected as:
static int return_EIO(void)
{
return -EIO;
}
#define EIO_ERROR ((void *) (return_EIO))
static struct inode_operations bad_inode_ops =
{
.create =
> > High probability is all you have. Cosmic radiation hitting your
> > computer will more likly cause problems, than colliding 64bit inode
> > numbers ;)
>
> Some of us have machines designed to cope with cosmic rays, and would be
> unimpressed with a decrease in reliability.
With the suggested
On Wed, Jan 03, 2007 at 01:33:31PM +0100, Miklos Szeredi wrote:
> High probability is all you have. Cosmic radiation hitting your
> computer will more likly cause problems, than colliding 64bit inode
> numbers ;)
Some of us have machines designed to cope with cosmic rays, and would be
unimpressed
On Tue, Jan 02, 2007 at 02:38:13PM -0700, Dan Williams ([EMAIL PROTECTED])
wrote:
> Would you have time to comment on the approach I have taken to
> implement a standard asynchronous memcpy interface? It seems it would
> be a good complement to what you are proposing. The entity that
> describes
Hello!
> High probability is all you have. Cosmic radiation hitting your
> computer will more likly cause problems, than colliding 64bit inode
> numbers ;)
No.
If you assign 64-bit inode numbers randomly, 2^32 of them are sufficient
to generate a collision with probability around 50%.
Hi!
> > > > > the use of a good hash function. The chance of an accidental
> > > > > collision is infinitesimally small. For a set of
> > > > >
> > > > > 100 files: 0.03%
> > > > >1,000,000 files: 0.03%
> > > >
> > > > I do not think we want to play with probabili
Trond Myklebust wrote:
> On Sun, 2006-12-31 at 16:25 -0500, Halevy, Benny wrote:
>> Trond Myklebust wrote:
>>>
>>> On Thu, 2006-12-28 at 15:07 -0500, Halevy, Benny wrote:
Mikulas Patocka wrote:
> BTW. how does (or how should?) NFS client deal with cache coherency if
> filehandles fo
> > > > the use of a good hash function. The chance of an accidental
> > > > collision is infinitesimally small. For a set of
> > > >
> > > > 100 files: 0.03%
> > > >1,000,000 files: 0.03%
> > >
> > > I do not think we want to play with probability like this. I mea
Hi!
> > > the use of a good hash function. The chance of an accidental
> > > collision is infinitesimally small. For a set of
> > >
> > > 100 files: 0.03%
> > >1,000,000 files: 0.03%
> >
> > I do not think we want to play with probability like this. I mean...
> >
31 matches
Mail list logo
