The release will be issued from openafs.org.
The release will be an official release from the openafs-devel-1_7_x
branch.
I'm not going to qualify it as beta any more than Apple qualifies a
new major release as beta. The code has been heavily tested and
implements just about everything an application can ask of a Windows
file system. It is better integrated with Windows than all of the
previous SMB based clients. Will it work perfectly for all
applications ever developed? Probably not. There are bound to be
some use cases that the code has simply never been exposed to. Will
the code work better than the SMB based client for most users?
Absolutely, especially if they are on Windows 7. Are there still
things that can be done to improve it? Definitely.
I will discuss the future as part of the release announcement.
Jeffrey Altman
On 9/6/2011 1:14 PM, Ben Howell wrote:
Will
that "release" on/about Sep. 15 be a alpha/beta/dev release, or an
actual public release?
- Ben
On 9/3/11 1:44 PM, Jeffrey Altman wrote:
On 9/3/2011 11:01 AM, Lars Schimmer wrote:
Hi!
Due to the outstanding Windows 7 bug annoying us very deeply,
we search
for a solution to this problem.
The solution to the Windows 7 bug is the OpenAFS for Windows
client with
native installable file system driver which will be released as
the
1.7.x development series.
Now that 1.6.0 has finally been released work will begin on
creating the
openafs-devel-1_7_x branch from which the IFS windows client
will be
issued. The first official release from OpenAFS.org will be
1.7.1. I
am hoping that we will be able to release on or around the 15th
of Sept.
The IFS client will bring some significant changes from the SMB
client.
No Loopback Adapter
-------------------
Now that a native IFS driver (afsredir.sys / afsredirlib.sys) is
used,
there is no need to install the Microsoft Loopback Adapter.
Sites that
have experienced problems due to the 10.254.254.253 address
registration
on multiple machines will be able to remove or disable the
adapter once
and for all.
No Delays After a Resume
------------------------
Windows Vista and 7 shutdown the network stack when the machine
is
suspended. This causes problems when the machine resumes
because the
network path to \\AFS is not immediately accessible. This is no
longer
an issue with the IFS driver.
No "AFS" server name collisions
-------------------------------
It is now possible to add a machine named "AFS" to domain or
subnet
without breaking the OpenAFS for Windows client.
Performance Improvements
------------------------
The transaction rate and throughput performance of the SMB
client was
limited by the "SMB client<-> loopback<-> SMB
server" performance:
54MB/sec maximum on 32-bit systems and 63MB/sec on 64-bit
systems. The
IFS client is capable of throughput rates to/from cache up to
800MB/sec
depending on the system I/O bus and backing store capabilities.
Symlinks to UNC Paths permit a cohesive name space
--------------------------------------------------
It has always been possible to create reparse points in MS DFS
that
refer to \\AFS paths. It is now possible to create symlinks in
AFS
that refer to arbitrary UNC paths. This permits the
construction of
a cohesive name space that spans across both AFS and DFS
storage.
Reparse Points
--------------
AFS Mount Points and Symlinks are exported by the file system
as Windows reparse points with a Microsoft assigned tag value.
Tools that are OpenAFS reparse point aware can create, query
and remove AFS symlinks and mount points without requiring
knowledge
of AFS pioctls. The explorer shell will be able to delete a
mount
point or symlink as part of a recursive directory tree removal
without
crossing into the reparse point target.
AFS Volumes are Windows File Systems
------------------------------------
Each AFS volume is represented in the Windows kernel as a
distinct
file system. This will permit AFS volume quotas to viewed as
Windows file system quotas.
Authentication Groups
---------------------
AFS Tokens are associated with Windows user names in the SMB
client.
With the IFS client, tokens are associated with Authentication
Groups.
By default, an authentication group is allocated for each User
SID
and Logon Session Id combination. In addition, it is possible
for
processes to create additional Authentication Groups. Each
thread in
a process can select an Authentication Group within the process
as the
active Authentication Group. This will permit AFS aware IIS
modules
to associate AFS credentials with a particular incoming
request. An
IIS implementation of File Drawers will be the preferred
implementation
once it is developed.
One of the significant benefits of Authentication Groups within
the
Windows environment is that Windows services (svchost.exe,
csrss.exe,
etc.) which impersonate user processes will seamlessly gain
access
to the user's AFS credentials for the lifetime of the
impersonation.
Explorer Shell Integration
--------------------------
The AFS Explorer Shell integration will gain support for symlink
and mount point overlay icons, tool tips, and Property dialog
pages
that replace many of the existing AFS Context Menu dialogs.
Jeffrey Altman
|
signature.asc
Description: OpenPGP digital signature
