Hi Rick,
Rick Macklem rmack...@uoguelph.ca wrote
in 468764384.310026.1314219682612.javamail.r...@erie.cs.uoguelph.ca:
rm It sounds like people have agreed that this is a reasonable solution.
rm If hrs@ can confirm that testing shows it fixes the original problem
rm (the ZFS file handles don't
Benjamin Kaduk wrote:
On Wed, 24 Aug 2011, Rick Macklem wrote:
afs
The current OpenAFS codebase uses the all-caps AFS. Judging by the
omitted text, perhaps this should change. (We also don't use VFS_SET
to
set it, which I filed a bug about.)
and here is my current rendition of the
Benjamin Kaduk wrote:
If we're confident that we won't ever fully fill the hash table, I
would
think that this should wrap around back to zero (or one?) instead of
overflowing.
Here's my updated patch (it will wrap to 1 the first time and then
exceed 255 if 1-255 are all in use).
---
Rick Macklem rmack...@uoguelph.ca wrote
in 468764384.310026.1314219682612.javamail.r...@erie.cs.uoguelph.ca:
rm Pawel Jakub Dawidek wrote:
rm On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote:
rm On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote:
rmWell, doesn't
On Thu, 25 Aug 2011, Rick Macklem wrote:
Benjamin Kaduk wrote:
If we're confident that we won't ever fully fill the hash table, I
would
think that this should wrap around back to zero (or one?) instead of
overflowing.
Here's my updated patch (it will wrap to 1 the first time and then
exceed
On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote:
On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote:
Pawel Jakub Dawidek wrote:
On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote:
Ok, I'll admit I wasn't very fond of a fixed table that would
Kostik Belousov kostik...@gmail.com wrote
in 20110824082119.gj17...@deviant.kiev.zoral.com.ua:
ko On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote:
ko On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote:
ko Pawel Jakub Dawidek wrote:
koOn Tue, Aug 23, 2011 at
On Wed, Aug 24, 2011 at 09:34:58PM +0900, Hiroki Sato wrote:
Kostik Belousov kostik...@gmail.com wrote
in 20110824082119.gj17...@deviant.kiev.zoral.com.ua:
ko On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote:
ko On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem
Kostik Belousov wrote:
On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote:
On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote:
Pawel Jakub Dawidek wrote:
On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote:
Ok, I'll admit I wasn't very fond of a
Kostik Belousov wrote:
On Wed, Aug 24, 2011 at 09:34:58PM +0900, Hiroki Sato wrote:
Kostik Belousov kostik...@gmail.com wrote
in 20110824082119.gj17...@deviant.kiev.zoral.com.ua:
ko On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek
wrote:
ko On Tue, Aug 23, 2011 at
On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote:
Kostik Belousov wrote:
On Wed, Aug 24, 2011 at 09:34:58PM +0900, Hiroki Sato wrote:
Kostik Belousov kostik...@gmail.com wrote
in 20110824082119.gj17...@deviant.kiev.zoral.com.ua:
ko On Tue, Aug 23, 2011 at 11:23:03PM
On (24/08/2011 21:34), Hiroki Sato wrote:
Kostik Belousov kostik...@gmail.com wrote
in 20110824082119.gj17...@deviant.kiev.zoral.com.ua:
ko On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote:
ko On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote:
ko Here's
Gleb Kurtsou gleb.kurt...@gmail.com wrote
in 20110824150235.GA46460@tops:
gl On (24/08/2011 21:34), Hiroki Sato wrote:
gl Kostik Belousov kostik...@gmail.com wrote
glin 20110824082119.gj17...@deviant.kiev.zoral.com.ua:
gl
gl ko On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub
Rick Macklem rmack...@uoguelph.ca wrote
in 920337541.272757.1314192294772.javamail.r...@erie.cs.uoguelph.ca:
rm Kostik Belousov wrote:
rm On Tue, Aug 23, 2011 at 11:23:03PM +0200, Pawel Jakub Dawidek wrote:
rm On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote:
rmPawel Jakub
On Thu, 25 Aug 2011, Hiroki Sato wrote:
My opinion is using a hash function which occurs no collision in the
well-known names is sufficient for our purpose because the number of
file systems on a running system is small anyway and not changed
frequently in most cases. I am not sure which
On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote:
On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote:
Well, doesn't this result in the same issue as the fixed table?
In other words, the developer has to supply the suggested byte for
fsid and make sure that it
Pawel Jakub Dawidek wrote:
On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote:
On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote:
Well, doesn't this result in the same issue as the fixed table?
In other words, the developer has to supply the suggested byte
for
Pawel Jakub Dawidek wrote:
On Wed, Aug 24, 2011 at 04:41:25PM +0300, Kostik Belousov wrote:
On Wed, Aug 24, 2011 at 09:36:37AM -0400, Rick Macklem wrote:
Well, doesn't this result in the same issue as the fixed table?
In other words, the developer has to supply the suggested byte
for
On Wed, 24 Aug 2011, Rick Macklem wrote:
afs
The current OpenAFS codebase uses the all-caps AFS. Judging by the
omitted text, perhaps this should change. (We also don't use VFS_SET to
set it, which I filed a bug about.)
and here is my current rendition of the patch. (I took Gleb's
On Sat, Aug 20, 2011 at 08:15:34PM -0400, Rick Macklem wrote:
Hiroki, could you please test the attached patch.
One problem with this patch is that I don't know how to create a fixed
table that matches what systems would already have been getting.
(I got the first 6 entries by booting a
Pawel Jakub Dawidek wrote:
On Sat, Aug 20, 2011 at 08:15:34PM -0400, Rick Macklem wrote:
Hiroki, could you please test the attached patch.
One problem with this patch is that I don't know how to create a
fixed
table that matches what systems would already have been getting.
(I got the
On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote:
Ok, I'll admit I wasn't very fond of a fixed table that would inevitably
get out of date someday, either.
I didn't think hashing for the cases not in the table was worth the effort,
but doing a hash instead of a table seems
Pawel Jakub Dawidek wrote:
On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote:
Ok, I'll admit I wasn't very fond of a fixed table that would
inevitably
get out of date someday, either.
I didn't think hashing for the cases not in the table was worth the
effort,
but doing a
On Tue, Aug 23, 2011 at 04:11:20PM -0400, Rick Macklem wrote:
Pawel Jakub Dawidek wrote:
On Tue, Aug 23, 2011 at 10:09:41AM -0400, Rick Macklem wrote:
Ok, I'll admit I wasn't very fond of a fixed table that would
inevitably
get out of date someday, either.
I didn't think hashing
Benjamin Kaduk wrote:
On Sun, 21 Aug 2011, Rick Macklem wrote:
Benjamin Kaduk wrote:
On Sat, 20 Aug 2011, Rick Macklem wrote:
If anyone thinks using a fixed table to assign vfc_typenum for
known
file system types is a bad idea, please let us know.
Fixed table sounds like a good
Benjamin Kaduk wrote:
On Sat, 20 Aug 2011, Rick Macklem wrote:
Yes, using vfs_getnewfsid() does not solve the issue.
I noticed that Solaris looked up a fixed array vfssw[] exactly for
the purpose. I think a table like it is a good solution for fixing
fsid for each file system.
--
Hi Rick,
Rick Macklem rmack...@uoguelph.ca wrote
in 59520805.118597.1313885734529.javamail.r...@erie.cs.uoguelph.ca:
rm Hiroki, could you please test the attached patch.
rm
rm One problem with this patch is that I don't know how to create a fixed
rm table that matches what systems would
On Sun, 21 Aug 2011, Rick Macklem wrote:
Benjamin Kaduk wrote:
On Sat, 20 Aug 2011, Rick Macklem wrote:
If anyone thinks using a fixed table to assign vfc_typenum for known
file system types is a bad idea, please let us know.
Fixed table sounds like a good plan.
Is there a reason
Hiroki Sato wrote:
Rick Macklem rmack...@uoguelph.ca wrote
in 1565511281.69213.1313764157732.javamail.r...@erie.cs.uoguelph.ca:
rm Hiroki Sato wrote:
rm fsid_guid = dmu_objset_fsid_guid(zfsvfs-z_os);
rm ASSERT((fsid_guid ~((1ULL56)-1)) == 0);
rm vfsp-vfs_fsid.val[0] = fsid_guid;
rm
Hiroki Sato wrote:
Rick Macklem rmack...@uoguelph.ca wrote
in 1565511281.69213.1313764157732.javamail.r...@erie.cs.uoguelph.ca:
rm Hiroki Sato wrote:
rm fsid_guid = dmu_objset_fsid_guid(zfsvfs-z_os);
rm ASSERT((fsid_guid ~((1ULL56)-1)) == 0);
rm vfsp-vfs_fsid.val[0] = fsid_guid;
rm
On Sat, 20 Aug 2011, Rick Macklem wrote:
Yes, using vfs_getnewfsid() does not solve the issue.
I noticed that Solaris looked up a fixed array vfssw[] exactly for
the purpose. I think a table like it is a good solution for fixing
fsid for each file system.
-- Hiroki
If anyone thinks using a
Hiroki Sato h...@freebsd.org wrote
in 20110819.002046.908756241495481148@allbsd.org:
hr Hi,
hr
hr I have experienced Stale NFS file handle issue when switching
hr between oldnfs and newnfs on a CURRENT box (NFS server exporting ZFS
hr mountpoints). The cause was that fsid was changed in
Hiroki Sato wrote:
Hiroki Sato h...@freebsd.org wrote
in 20110819.002046.908756241495481148@allbsd.org:
hr Hi,
hr
hr I have experienced Stale NFS file handle issue when switching
hr between oldnfs and newnfs on a CURRENT box (NFS server exporting
ZFS
hr mountpoints). The cause was
Hiroki Sato wrote:
Hiroki Sato h...@freebsd.org wrote
in 20110819.002046.908756241495481148@allbsd.org:
hr Hi,
hr
hr I have experienced Stale NFS file handle issue when switching
hr between oldnfs and newnfs on a CURRENT box (NFS server exporting
ZFS
hr mountpoints). The cause was
Rick Macklem rmack...@uoguelph.ca wrote
in 1565511281.69213.1313764157732.javamail.r...@erie.cs.uoguelph.ca:
rm Hiroki Sato wrote:
rm fsid_guid = dmu_objset_fsid_guid(zfsvfs-z_os);
rm ASSERT((fsid_guid ~((1ULL56)-1)) == 0);
rm vfsp-vfs_fsid.val[0] = fsid_guid;
rm vfsp-vfs_fsid.val[1] =
Hi,
I have experienced Stale NFS file handle issue when switching
between oldnfs and newnfs on a CURRENT box (NFS server exporting ZFS
mountpoints). The cause was that fsid was changed in the following
conditions and not in the NFS subsystem itself, but I am wondering if
these are expected
36 matches
Mail list logo
