"Steven J. Magnani" writes:
>> Hm, not really, if the file handle is including parent ino. ext2 will
>> get the latest parent ino, because it checks parent of inode of file
>> handle.
>
> Can you point me to the code for this? The code I see looks pretty
> congruent to what I think the FAT code
On Tue, 2012-07-10 at 06:34 +0900, OGAWA Hirofumi wrote:
> "Steven J. Magnani" writes:
>
> >> Ah, i_ino. I was talking about i_pos. Well, so, what happens if the
> >> child was renamed to other parent on NFS server machine (not via nfs
> >> client)? The file handle would be including the old
"Steven J. Magnani" writes:
>> Ah, i_ino. I was talking about i_pos. Well, so, what happens if the
>> child was renamed to other parent on NFS server machine (not via nfs
>> client)? The file handle would be including the old i_ino, and the old
>> i_ino on file handle is still vaild as old
On Tue, 2012-07-10 at 04:10 +0900, OGAWA Hirofumi wrote:
> "Steven J. Magnani" writes:
>
> >> > >> > Interesting idea. I think this, and reformulating the FAT NFS file
> >> > >> > handle to include the parent's i_ino, will greatly simplify (and
> >> > >> > speed
> >> > >> > up) the code.
> >>
"Steven J. Magnani" writes:
>> > >> > Interesting idea. I think this, and reformulating the FAT NFS file
>> > >> > handle to include the parent's i_ino, will greatly simplify (and speed
>> > >> > up) the code.
>> > >>
>> > >> Does it work even if the inode was rename()'ed?
>> > >
>> > > AFAICT.
On Mon, 2012-07-09 at 12:09 -0500, Steven J. Magnani wrote:
> On Mon, 2012-07-09 at 11:27 -0500, Steven J. Magnani wrote:
> > On Tue, 2012-07-10 at 01:10 +0900, OGAWA Hirofumi wrote:
> > > If the inode is not on cache anymore, is there the possibility that
> > > selects the wrong parent? IIRC,
On Mon, 2012-07-09 at 11:27 -0500, Steven J. Magnani wrote:
> On Tue, 2012-07-10 at 01:10 +0900, OGAWA Hirofumi wrote:
> > "Steven J. Magnani" writes:
> >
> > > On Mon, 2012-07-09 at 22:43 +0900, OGAWA Hirofumi wrote:
> > >> "Steven J. Magnani" writes:
> > >>
> > >> >> We need the key,
On Tue, 2012-07-10 at 01:10 +0900, OGAWA Hirofumi wrote:
> "Steven J. Magnani" writes:
>
> > On Mon, 2012-07-09 at 22:43 +0900, OGAWA Hirofumi wrote:
> >> "Steven J. Magnani" writes:
> >>
> >> >> We need the key, possible key is - if it is only directory, FAT may be
> >> >> able to use
"Steven J. Magnani" writes:
> On Mon, 2012-07-09 at 22:43 +0900, OGAWA Hirofumi wrote:
>> "Steven J. Magnani" writes:
>>
>> >> We need the key, possible key is - if it is only directory, FAT may be
>> >> able to use i_start as additional search key.
>> >
>> > Interesting idea. I think this,
On Mon, 2012-07-09 at 22:43 +0900, OGAWA Hirofumi wrote:
> "Steven J. Magnani" writes:
>
> >> We need the key, possible key is - if it is only directory, FAT may be
> >> able to use i_start as additional search key.
> >
> > Interesting idea. I think this, and reformulating the FAT NFS file
> >
"Steven J. Magnani" writes:
>> How do you prevent to modify or free the those inode/blocks from other
>> path? Yeah, it is racy. And if races is not solved, that's simply wrong
>> and not solution.
>>
>> Although I'm not thinking deeply about NFS support on FAT. Just a idea,
>> the one of
On Sun, 2012-07-08 at 02:00 +0900, OGAWA Hirofumi wrote:
> "Steven J. Magnani" writes:
>
> >> You mean the unhashed inode is created by ->get_parent()? If so, the
> >> root cause sounds like ->get_parent() itself. If not, I'm not
> >> understanding the meaning of the temporary/unofficial inode
On Sun, 2012-07-08 at 02:00 +0900, OGAWA Hirofumi wrote:
Steven J. Magnani st...@digidescorp.com writes:
You mean the unhashed inode is created by -get_parent()? If so, the
root cause sounds like -get_parent() itself. If not, I'm not
understanding the meaning of the temporary/unofficial
Steven J. Magnani st...@digidescorp.com writes:
How do you prevent to modify or free the those inode/blocks from other
path? Yeah, it is racy. And if races is not solved, that's simply wrong
and not solution.
Although I'm not thinking deeply about NFS support on FAT. Just a idea,
the one
On Mon, 2012-07-09 at 22:43 +0900, OGAWA Hirofumi wrote:
Steven J. Magnani st...@digidescorp.com writes:
We need the key, possible key is - if it is only directory, FAT may be
able to use i_start as additional search key.
Interesting idea. I think this, and reformulating the FAT NFS
Steven J. Magnani st...@digidescorp.com writes:
On Mon, 2012-07-09 at 22:43 +0900, OGAWA Hirofumi wrote:
Steven J. Magnani st...@digidescorp.com writes:
We need the key, possible key is - if it is only directory, FAT may be
able to use i_start as additional search key.
Interesting
On Tue, 2012-07-10 at 01:10 +0900, OGAWA Hirofumi wrote:
Steven J. Magnani st...@digidescorp.com writes:
On Mon, 2012-07-09 at 22:43 +0900, OGAWA Hirofumi wrote:
Steven J. Magnani st...@digidescorp.com writes:
We need the key, possible key is - if it is only directory, FAT may be
On Mon, 2012-07-09 at 11:27 -0500, Steven J. Magnani wrote:
On Tue, 2012-07-10 at 01:10 +0900, OGAWA Hirofumi wrote:
Steven J. Magnani st...@digidescorp.com writes:
On Mon, 2012-07-09 at 22:43 +0900, OGAWA Hirofumi wrote:
Steven J. Magnani st...@digidescorp.com writes:
We
On Mon, 2012-07-09 at 12:09 -0500, Steven J. Magnani wrote:
On Mon, 2012-07-09 at 11:27 -0500, Steven J. Magnani wrote:
On Tue, 2012-07-10 at 01:10 +0900, OGAWA Hirofumi wrote:
If the inode is not on cache anymore, is there the possibility that
selects the wrong parent? IIRC, NFS
Steven J. Magnani st...@digidescorp.com writes:
Interesting idea. I think this, and reformulating the FAT NFS file
handle to include the parent's i_ino, will greatly simplify (and speed
up) the code.
Does it work even if the inode was rename()'ed?
AFAICT. I don't see why
On Tue, 2012-07-10 at 04:10 +0900, OGAWA Hirofumi wrote:
Steven J. Magnani st...@digidescorp.com writes:
Interesting idea. I think this, and reformulating the FAT NFS file
handle to include the parent's i_ino, will greatly simplify (and
speed
up) the code.
Does it
Steven J. Magnani st...@digidescorp.com writes:
Ah, i_ino. I was talking about i_pos. Well, so, what happens if the
child was renamed to other parent on NFS server machine (not via nfs
client)? The file handle would be including the old i_ino, and the old
i_ino on file handle is still vaild
On Tue, 2012-07-10 at 06:34 +0900, OGAWA Hirofumi wrote:
Steven J. Magnani st...@digidescorp.com writes:
Ah, i_ino. I was talking about i_pos. Well, so, what happens if the
child was renamed to other parent on NFS server machine (not via nfs
client)? The file handle would be including
Steven J. Magnani st...@digidescorp.com writes:
Hm, not really, if the file handle is including parent ino. ext2 will
get the latest parent ino, because it checks parent of inode of file
handle.
Can you point me to the code for this? The code I see looks pretty
congruent to what I think the
"Steven J. Magnani" writes:
>> You mean the unhashed inode is created by ->get_parent()? If so, the
>> root cause sounds like ->get_parent() itself. If not, I'm not
>> understanding the meaning of the temporary/unofficial inode here.
>
> Maybe "private" is a better word than "unofficial".
On Sat, 2012-07-07 at 15:03 +0900, OGAWA Hirofumi wrote:
> "Steven J. Magnani" writes:
>
> > On Sat, 2012-07-07 at 06:07 +0900, OGAWA Hirofumi wrote:
> >> "Steven J. Magnani" writes:
> >>
> >> > On Wed, 2012-07-04 at 20:07 +0900, OGAWA Hirofumi wrote:
> >> >> Please don't add new
"Steven J. Magnani" writes:
> On Sat, 2012-07-07 at 06:07 +0900, OGAWA Hirofumi wrote:
>> "Steven J. Magnani" writes:
>>
>> > On Wed, 2012-07-04 at 20:07 +0900, OGAWA Hirofumi wrote:
>> >> Please don't add new lock_super() usage if it is not necessary. Almost
>> >> all of lock_super() just
Steven J. Magnani st...@digidescorp.com writes:
On Sat, 2012-07-07 at 06:07 +0900, OGAWA Hirofumi wrote:
Steven J. Magnani st...@digidescorp.com writes:
On Wed, 2012-07-04 at 20:07 +0900, OGAWA Hirofumi wrote:
Please don't add new lock_super() usage if it is not necessary. Almost
all
On Sat, 2012-07-07 at 15:03 +0900, OGAWA Hirofumi wrote:
Steven J. Magnani st...@digidescorp.com writes:
On Sat, 2012-07-07 at 06:07 +0900, OGAWA Hirofumi wrote:
Steven J. Magnani st...@digidescorp.com writes:
On Wed, 2012-07-04 at 20:07 +0900, OGAWA Hirofumi wrote:
Please don't
Steven J. Magnani st...@digidescorp.com writes:
You mean the unhashed inode is created by -get_parent()? If so, the
root cause sounds like -get_parent() itself. If not, I'm not
understanding the meaning of the temporary/unofficial inode here.
Maybe private is a better word than unofficial.
On Sat, 2012-07-07 at 06:07 +0900, OGAWA Hirofumi wrote:
> "Steven J. Magnani" writes:
>
> > On Wed, 2012-07-04 at 20:07 +0900, OGAWA Hirofumi wrote:
> >> Please don't add new lock_super() usage if it is not necessary. Almost
> >> all of lock_super() just replaced lock_kernel() usage. It
"Steven J. Magnani" writes:
> On Wed, 2012-07-04 at 20:07 +0900, OGAWA Hirofumi wrote:
>> Please don't add new lock_super() usage if it is not necessary. Almost
>> all of lock_super() just replaced lock_kernel() usage. It rather should
>> be removed in future. Probably, this should use
On Wed, 2012-07-04 at 20:07 +0900, OGAWA Hirofumi wrote:
> Please don't add new lock_super() usage if it is not necessary. Almost
> all of lock_super() just replaced lock_kernel() usage. It rather should
> be removed in future. Probably, this should use inode->i_mutex instead.
>
> BTW, the
On Wed, 2012-07-04 at 20:07 +0900, OGAWA Hirofumi wrote:
Please don't add new lock_super() usage if it is not necessary. Almost
all of lock_super() just replaced lock_kernel() usage. It rather should
be removed in future. Probably, this should use inode-i_mutex instead.
BTW, the above
Steven J. Magnani st...@digidescorp.com writes:
On Wed, 2012-07-04 at 20:07 +0900, OGAWA Hirofumi wrote:
Please don't add new lock_super() usage if it is not necessary. Almost
all of lock_super() just replaced lock_kernel() usage. It rather should
be removed in future. Probably, this should
On Sat, 2012-07-07 at 06:07 +0900, OGAWA Hirofumi wrote:
Steven J. Magnani st...@digidescorp.com writes:
On Wed, 2012-07-04 at 20:07 +0900, OGAWA Hirofumi wrote:
Please don't add new lock_super() usage if it is not necessary. Almost
all of lock_super() just replaced lock_kernel() usage.
36 matches
Mail list logo
