Hi All, Has anyone ever put any thought (or code) into an (Open)AFS-based virtual block device backend for Xen? This driver would use a large file stored in AFS as its underlying "device", as opposed to a loop device or an LVM or physical device. If I understand Xen''s interface architecture correctly, this backend would be stacked something like this: ext3 or other standard filesystem in domN existing block device frontend in domN new "afs file" backend in dom0 large file in /afs in dom0 AFS client in dom0 AFS server somewhere on net You would configure this using something like: disk = [''afsfile:/full/path/to/afs/file,sda1,w''] Only dom0 would need to be an AFS client; the kerberos ticket(s) would be owned and renewed by management code in dom0 only; the other domains would not need to be kerberized, would not have access to any keytabs in dom0, etc. Each domain could have a single kerberos ID and its own AFS volume(s) for storage of its "disks", but the individual users or daemons in each domain would not be aware of kerberos at all. I think most of this could be done in python -- the backend driver itself might be a relatively thin layer to translate block addressing to and from file byte locations, talk to the frontend, and do a periodic fsync() on the underlying file to write the changes back to the AFS server. There''d be nothing to keep someone from using this backend on top of ordinary, non-AFS files; this might provide better performance (one less layer) than going through the loop device driver. Perhaps the VBD type name might even want to be ''rawfile'' or somesuch instead of ''afsfile'', though an AFS-specific bind/unbind script might be useful for token management. Some potential FAQ answers, before I get bombarded: ;-) Q: Why is this useful? A: Because AFS can be run over the Internet, has excellent security, client-side caching, server-side replication and snapshots, and would lend itself well to an environment where the AFS clients and servers might be in different geographical locations, owned by two different parties, hosting Xen domN filesystems owned in turn by other parties. Q: Why not just use native AFS in the unprivileged domains? A: Because then those domains would have to be kerberized AFS clients, and the users/owners of those domains would have to have kerberos ID''s, they''d have to be knowledgable in AFS ACLs, the AFS directory-based security model, daemon token renewal, and so on. The root-user domain owners would have to know how to manage kerberos users, and they''d have to have kerberos admin rights. This is too much to expect. The typical Xen customer wants to be able to just use normal *nix tools to add or delete a user -- that won''t work with kerberos. All users of all domains would be in the same kerberos namespace too -- there could be only one "jim" across all domains, even though those domains are supposed to be independent *nix machines owned by different parties -- very difficult to explain. Q: Why not just use a loop device on top of AFS, with the ''file:'' VBD type? A: Loop devices on top of AFS files hang with large volumes of I/O -- looks like a deadlock of some sort (in my tests, a dd of around 2-300 Mb into an AFS-based loop device appears to consistently hang the kernel, even with a 500Mb or larger AFS cache). In addition, an unmodified loop.c will not fsync() the underlying file; changes won''t get written back to the AFS server until loop teardown. I''ve added an fsync() to the worker thread of loop.c to take care of this every few seconds; that seems to work but I can''t really stress test it much because of the hang problem. Q: Why not use iSCSI, nbd, drbd, gnbd, or enbd? A: While these each seem to do their job well, none offer all of the maturity, client-side caching, WAN-optimized protocols, volume management, backups, easy snapshots, scalability, central administration, redundancy, replication, or kerberized security of AFS. What did I miss? ;-) Steve -- Stephen G. Traugott (KG6HDQ) UNIX/Linux Infrastructure Architect, TerraLuna LLC stevegt@TerraLuna.Org http://www.stevegt.com -- http://Infrastructures.Org ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Thu, Dec 23, 2004 at 12:55:58AM -0800, Steve Traugott wrote:> Hi All, > > Has anyone ever put any thought (or code) into an (Open)AFS-based > virtual block device backend for Xen? This driver would use a large > file stored in AFS as its underlying "device", as opposed to a loop > device or an LVM or physical device. If I understand Xen''s interface > architecture correctly, this backend would be stacked something like > this: > > ext3 or other standard filesystem in domN > existing block device frontend in domN > new "afs file" backend in dom0 > large file in /afs in dom0 > AFS client in dom0 > AFS server somewhere on net > > You would configure this using something like: > > disk = [''afsfile:/full/path/to/afs/file,sda1,w''] > > Only dom0 would need to be an AFS client; the kerberos ticket(s) would > be owned and renewed by management code in dom0 only; the other domains > would not need to be kerberized, would not have access to any keytabs in > dom0, etc. Each domain could have a single kerberos ID and its own AFS > volume(s) for storage of its "disks", but the individual users or > daemons in each domain would not be aware of kerberos at all. > > I think most of this could be done in python -- the backend driver > itself might be a relatively thin layer to translate block addressing to > and from file byte locations, talk to the frontend, and do a periodic > fsync() on the underlying file to write the changes back to the AFS > server. > > There''d be nothing to keep someone from using this backend on top of > ordinary, non-AFS files; this might provide better performance (one less > layer) than going through the loop device driver. Perhaps the VBD type > name might even want to be ''rawfile'' or somesuch instead of ''afsfile'', > though an AFS-specific bind/unbind script might be useful for token > management. > > Some potential FAQ answers, before I get bombarded: ;-) > > Q: Why is this useful? > A: Because AFS can be run over the Internet, has excellent security, > client-side caching, server-side replication and snapshots, and > would lend itself well to an environment where the AFS clients and > servers might be in different geographical locations, owned by two > different parties, hosting Xen domN filesystems owned in turn by > other parties. > > Q: Why not just use native AFS in the unprivileged domains? > A: Because then those domains would have to be kerberized AFS clients, > and the users/owners of those domains would have to have kerberos > ID''s, they''d have to be knowledgable in AFS ACLs, the AFS > directory-based security model, daemon token renewal, and so on. > The root-user domain owners would have to know how to manage > kerberos users, and they''d have to have kerberos admin rights. This > is too much to expect. The typical Xen customer wants to be able to > just use normal *nix tools to add or delete a user -- that won''t work > with kerberos. All users of all domains would be in the same > kerberos namespace too -- there could be only one "jim" across all > domains, even though those domains are supposed to be independent > *nix machines owned by different parties -- very difficult to > explain. > > Q: Why not just use a loop device on top of AFS, with the ''file:'' > VBD type? > A: Loop devices on top of AFS files hang with large volumes of > I/O -- looks like a deadlock of some sort (in my tests, a dd of > around 2-300 Mb into an AFS-based loop device appears to > consistently hang the kernel, even with a 500Mb or larger AFS > cache). In addition, an unmodified loop.c will not fsync() the > underlying file; changes won''t get written back to the AFS server > until loop teardown. I''ve added an fsync() to the worker thread of > loop.c to take care of this every few seconds; that seems to work > but I can''t really stress test it much because of the hang problem. > > Q: Why not use iSCSI, nbd, drbd, gnbd, or enbd? > A: While these each seem to do their job well, none offer all of the > maturity, client-side caching, WAN-optimized protocols, volume > management, backups, easy snapshots, scalability, central > administration, redundancy, replication, or kerberized security of > AFS. > > What did I miss? ;-)That it''s already possible to use normal files. :) So, no need for explicit support in xen. If your dom0 already knows and uses afs, just specify the file in the xen configuration: disk = [ ''file:/afs/file,sda1,w'' ] Regards, Luciano Rocha ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > Q: Why not just use a loop device on top of AFS, with the ''file:'' > > VBD type? > > A: Loop devices on top of AFS files hang with large volumes of > > I/O -- looks like a deadlock of some sort (in my tests, a dd of > > around 2-300 Mb into an AFS-based loop device appears to > > consistently hang the kernel, even with a 500Mb or larger AFS > > cache). In addition, an unmodified loop.c will not fsync() the > > underlying file; changes won''t get written back to the AFS server > > until loop teardown. I''ve added an fsync() to the worker thread of > > loop.c to take care of this every few seconds; that seems to work > > but I can''t really stress test it much because of the hang problem. > > That it''s already possible to use normal files. :) > > So, no need for explicit support in xen. If your dom0 already knows and > uses afs, just specify the file in the xen configuration: > > disk = [ ''file:/afs/file,sda1,w'' ]The OP did have an explanation why he didn''t want to use a loop device. However, I would say that the correct approach here is probably to enhance/fix the existign loop support rather than adding a whole new backend driver. -- Keir ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Thu, Dec 23, 2004 at 10:42:18AM +0000, Keir Fraser wrote:> > > Q: Why not just use a loop device on top of AFS, with the ''file:'' > > > VBD type? > > > A: Loop devices on top of AFS files hang with large volumes of > > > I/O -- looks like a deadlock of some sort (in my tests, a dd of > > > around 2-300 Mb into an AFS-based loop device appears to > > > consistently hang the kernel, even with a 500Mb or larger AFS > > > cache). In addition, an unmodified loop.c will not fsync() the > > > underlying file; changes won''t get written back to the AFS server > > > until loop teardown. I''ve added an fsync() to the worker thread of > > > loop.c to take care of this every few seconds; that seems to work > > > but I can''t really stress test it much because of the hang problem. > > > > That it''s already possible to use normal files. :) > > > > So, no need for explicit support in xen. If your dom0 already knows and > > uses afs, just specify the file in the xen configuration: > > > > disk = [ ''file:/afs/file,sda1,w'' ] > > The OP did have an explanation why he didn''t want to use a loop > device. However, I would say that the correct approach here is > probably to enhance/fix the existign loop support rather than adding a > whole new backend driver.I was unaware that the ''file'' backend used loop devices. The documentation doesn''t state that. Regards, Luciano Rocha ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Thu, Dec 23, 2004 at 10:37:17AM +0000, Luciano Miguel Ferreira Rocha wrote:> On Thu, Dec 23, 2004 at 12:55:58AM -0800, Steve Traugott wrote: > > Q: Why not just use a loop device on top of AFS, with the ''file:'' > > VBD type? > > A: Loop devices on top of AFS files hang with large volumes of > > I/O -- looks like a deadlock of some sort (in my tests, a dd of > > around 2-300 Mb into an AFS-based loop device appears to > > consistently hang the kernel, even with a 500Mb or larger AFS > > cache). In addition, an unmodified loop.c will not fsync() the > > underlying file; changes won''t get written back to the AFS server > > until loop teardown. I''ve added an fsync() to the worker thread of > > loop.c to take care of this every few seconds; that seems to work > > but I can''t really stress test it much because of the hang problem.> > What did I miss? ;-) > > That it''s already possible to use normal files. :) > > So, no need for explicit support in xen. If your dom0 already knows and > uses afs, just specify the file in the xen configuration: > > disk = [ ''file:/afs/file,sda1,w'' ]Already covered in the above FAQ answer. ;-) The ''file:...'' VBD type just uses the loop device driver underneath. Won''t work on top of AFS. Steve -- Stephen G. Traugott (KG6HDQ) UNIX/Linux Infrastructure Architect, TerraLuna LLC stevegt@TerraLuna.Org http://www.stevegt.com -- http://Infrastructures.Org ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> I think most of this could be done in python -- the backend > driver itself might be a relatively thin layer to translate > block addressing to and from file byte locations, talk to the > frontend, and do a periodic > fsync() on the underlying file to write the changes back to > the AFS server.You don''t want to do it in python, but you do want to do it in user space to avoid the deadlocks with AFS. The blocktap backend driver is what you want. I''m not sure of it''s current state, but the plan is to enable you to terminate a blk device channel in user-space. A future revision of blocktap could use kiovec''s to avoid having to copy data into user space, and thus would give good performance. The kernel loop driver works fine with most file systems, but AFS is very ''special'' and doesn''t really follow the design of the other file systems. Of course, you could use ''unfsd -r'' and export your AFS root file systems via same-machine NFS. This works pretty well, but I can''t say I''ve hammered it. Ian ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Thu, Dec 23, 2004 at 10:42:18AM +0000, Keir Fraser wrote:> > > Q: Why not just use a loop device on top of AFS, with the ''file:'' > > > VBD type? > > > A: Loop devices on top of AFS files hang with large volumes of > > > I/O -- looks like a deadlock of some sort (in my tests, a dd of > > > around 2-300 Mb into an AFS-based loop device appears to > > > consistently hang the kernel, even with a 500Mb or larger AFS > > > cache). In addition, an unmodified loop.c will not fsync() the > > > underlying file; changes won''t get written back to the AFS server > > > until loop teardown. I''ve added an fsync() to the worker thread of > > > loop.c to take care of this every few seconds; that seems to work > > > but I can''t really stress test it much because of the hang problem. > > > > That it''s already possible to use normal files. :) > > > > So, no need for explicit support in xen. If your dom0 already knows and > > uses afs, just specify the file in the xen configuration: > > > > disk = [ ''file:/afs/file,sda1,w'' ] > > The OP did have an explanation why he didn''t want to use a loop > device. However, I would say that the correct approach here is > probably to enhance/fix the existign loop support rather than adding a > whole new backend driver.I know that seems like the more modular approach, and I tried that first, got as far as fixing the fsync() problem, ran into the hangs. Those are consistent, but time-consuming to reproduce. But even if we clean them up we still would have an extra layer in between the block backend and AFS, a layer that could be gotten rid of. I might be convinced to have another go at it; the question is, which is more worth the development effort? Xen''s architecture is certainly a lot cleaner, and might be easier to write a native file-based backend for, than trying to troubleshoot and clean up the pile of spaghetti that is the loop.c data flow. I''m open to suggestions. Steve -- Stephen G. Traugott (KG6HDQ) UNIX/Linux Infrastructure Architect, TerraLuna LLC stevegt@TerraLuna.Org http://www.stevegt.com -- http://Infrastructures.Org ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Hi Ian, On Thu, Dec 23, 2004 at 11:41:08AM -0000, Ian Pratt wrote:> > I think most of this could be done in python -- the backend > > driver itself might be a relatively thin layer to translate > > block addressing to and from file byte locations, talk to the > > frontend, and do a periodic > > fsync() on the underlying file to write the changes back to > > the AFS server. > > You don''t want to do it in python, but you do want to do it in user > space to avoid the deadlocks with AFS.I said that badly -- by "most of this" I mean ticket and token management etc. I was still thinking C for the backend itself. But now that you mention it...> The blocktap backend driver is what you want. I''m not sure of it''s > current state, but the plan is to enable you to terminate a blk device > channel in user-space.Cool! Where was the most recent version of that?> The kernel loop driver works fine with most file systems, but AFS is > very ''special'' and doesn''t really follow the design of the other file > systems.Yep. :-}> Of course, you could use ''unfsd -r'' and export your AFS root file > systems via same-machine NFS. This works pretty well, but I can''t say > I''ve hammered it.I''m one of the folks who ran into the NFS root hangs early on -- trying very hard to get off of it, hence this messing about with alternatives. Granted, I''m not using same-machine NFS, don''t know how much that would reduce the hangs. One variation on that theme that I have tested is an enbd server running on an AFS client, serving block devices to dom0 on another machine. ;-) Slow, but seems stable. Haven''t tried same-machine with that either, because it eats about 30% CPU on the enbd server under load. Blocktap sounds closer to ideal; at least we''d get rid of the network stack transit. Steve -- Stephen G. Traugott (KG6HDQ) UNIX/Linux Infrastructure Architect, TerraLuna LLC stevegt@TerraLuna.Org http://www.stevegt.com -- http://Infrastructures.Org ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > The blocktap backend driver is what you want. I''m not sure of it''s > > current state, but the plan is to enable you to terminate a > blk device > > channel in user-space. > > Cool! Where was the most recent version of that?Unstable tree, but probably works in 2.0 too.> > Of course, you could use ''unfsd -r'' and export your AFS root file > > systems via same-machine NFS. This works pretty well, but I > can''t say > > I''ve hammered it. > > I''m one of the folks who ran into the NFS root hangs early on > -- trying very hard to get off of it, hence this messing > about with alternatives. > Granted, I''m not using same-machine NFS, don''t know how much > that would reduce the hangs.Do you still see hangs with 2.6.9 kernels?> One variation on that theme that I have tested is an enbd > server running on an AFS client, serving block devices to > dom0 on another machine. ;-) Slow, but seems stable. > Haven''t tried same-machine with that either, because it eats > about 30% CPU on the enbd server under load.We use redhat gnbd in preference to enbd. Ian ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> The blocktap backend driver is what you want. I''m not sure of it''s > current state, but the plan is to enable you to terminate a blk device > channel in user-space.The driver currently does this. There is a rather dated version of it in the unstable tree... It lets you either terminate a blkif connection in userspace of a tap domain, or intercept in-flight requests by proxying them to user-space before they are passed along to a normal backend. Data pages provided by the front end are mapped up to user space by the tap driver, so there is no copying along that path. I''ve got a newer and more, um, robust ;) version of the blktap stuff in my repository... it''s a bit tied up with some of the other device channel updates that we have been looking at lately though -- so it''s not in a state to integrate directly to the public trees. I''d imagine that much of this stuff should be ready to go into unstable in the next few weeks... hopefully along with a nettap as well. Steve, if you need the tap more urgently than this, I can likely sort out an interim version. If you can wait until early january though, that might be best.> A future revision of blocktap could use kiovec''s to avoid having to copy > data into user space, and thus would give good performance.arranging direct i/o to the mapped data pages is clearly the thing to do. I''ll take a look at the kvec stuff over the next few weeks as well. a. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Thu, Dec 23, 2004 at 10:56:52AM +0000, Luciano Miguel Ferreira Rocha wrote:> I was unaware that the ''file'' backend used loop devices. The > documentation doesn''t state that.I had to know, so I went digging for it -- see the ''losetup'' commands in /etc/xen/scripts/block-file -- this setup script is called by the block() function in /lib/python/xen/xend/Blkctl.py, which is in turn called by attach() in xend/server/blkif.py, etc. Steve -- Stephen G. Traugott (KG6HDQ) UNIX/Linux Infrastructure Architect, TerraLuna LLC stevegt@TerraLuna.Org http://www.stevegt.com -- http://Infrastructures.Org ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Thu, Dec 23, 2004 at 12:31:22PM -0000, Ian Pratt wrote:> > > The blocktap backend driver is what you want. I''m not sure of it''s > > > current state, but the plan is to enable you to terminate a > > blk device > > > channel in user-space. > > > > Cool! Where was the most recent version of that? > > Unstable tree, but probably works in 2.0 too.Thanks -- I''m going to look at it over the holidays.> > I''m one of the folks who ran into the NFS root hangs early on > > -- trying very hard to get off of it, hence this messing > > about with alternatives. > > Granted, I''m not using same-machine NFS, don''t know how much > > that would reduce the hangs. > > Do you still see hangs with 2.6.9 kernels?We''re not on 2.6.x yet, due to lagging OpenAFS support. I am seeing the complaints about NFS roots in early 2.6 kernels though -- do you have any reason to think it''s better now than 2.4?> > One variation on that theme that I have tested is an enbd > > server running on an AFS client, serving block devices to > > dom0 on another machine. ;-) Slow, but seems stable. > > Haven''t tried same-machine with that either, because it eats > > about 30% CPU on the enbd server under load. > > We use redhat gnbd in preference to enbd.I noticed that. You said something last October about running both the gnbd client and server in dom0 on a number of machines -- I thought importing from the same machine would cause a deadlock, so I''ve been trying to figure out what you''re actually doing. Steve -- Stephen G. Traugott (KG6HDQ) UNIX/Linux Infrastructure Architect, TerraLuna LLC stevegt@TerraLuna.Org http://www.stevegt.com -- http://Infrastructures.Org ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> > Do you still see hangs with 2.6.9 kernels? > > We''re not on 2.6.x yet, due to lagging OpenAFS support.Interesting. Is 2.6 OpenAFS support being actively worked on? Who by?> I am > seeing the complaints about NFS roots in early 2.6 kernels > though -- do you have any reason to think it''s better now than 2.4?Use dom0 2.4 for AFS support, run unfsd to export to 2.6 domU''s. It''s well worth a try...> > > One variation on that theme that I have tested is an enbd server > > > running on an AFS client, serving block devices to dom0 > on another > > > machine. ;-) Slow, but seems stable. > > > Haven''t tried same-machine with that either, because it > eats about > > > 30% CPU on the enbd server under load. > > > > We use redhat gnbd in preference to enbd. > > I noticed that. You said something last October about > running both the gnbd client and server in dom0 on a number > of machines -- I thought importing from the same machine > would cause a deadlock, so I''ve been trying to figure out > what you''re actually doing.It doesn''t make sense to do a loopback import (not sure whether it would deadlock or not, but I can believe it). Running client and server in dom0 and importing/exporting to other machines seems to work fine. Ian ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Thu, Dec 23, 2004 at 12:36:30PM +0000, Andrew Warfield wrote:> I''ve got a newer and more, um, robust ;) version of the blktap stuff > in my repository... it''s a bit tied up with some of the other device > channel updates that we have been looking at lately though -- so it''s > not in a state to integrate directly to the public trees. I''d imagine > that much of this stuff should be ready to go into unstable in the > next few weeks... hopefully along with a nettap as well. > > Steve, if you need the tap more urgently than this, I can likely sort > out an interim version. If you can wait until early january though, > that might be best.Thanks Andrew! I''m going to take a look at what''s in unstable first, try to understand and play with it. I''d expect that''s going to take me through the holidays. Steve -- Stephen G. Traugott (KG6HDQ) UNIX/Linux Infrastructure Architect, TerraLuna LLC stevegt@TerraLuna.Org http://www.stevegt.com -- http://Infrastructures.Org ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
> Thanks Andrew! I''m going to take a look at what''s in unstable first, > try to understand and play with it. I''d expect that''s going to take me > through the holidays.no worries at all... it''s great to see a another potential use for the tap There is some user-space code to attach to it and a bit of documentation around here somewhere. I''ll see if it works with what is in unstable and try to forward a tarball along to you later this afternoon. All the driver on its own gives you is a character device to map in the control rings and data pages... the userspace stuff lets you add handlers for block requests. a. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Steve Traugott <stevegt@TerraLuna.Org> wrote: Hi, The idea sounds nice to me, but I''ve one question> I think most of this could be done in python -- the backend driver > itself might be a relatively thin layer to translate block addressing to > and from file byte locations, talk to the frontend, and do a periodic > fsync() on the underlying file to write the changes back to the AFS > server.Wouldn''t OpenAFS send the complete file to the server when the fsync() is called and creates lots of network traffik? And wouldn''t be the file/backend locked until the fsync() is done, which could take some time if you''ll have a few GB. regards Johannes -->>Du weisst, das Du Usenetjunkie bist wenn Du |Autoren: H. Koepke, >>-keine 11 Tage ohne Netdigest leben moechtest |C. Peper, C. Garbers >-Hanno Inbox lesen willst, um noch schneller an die Postings zu kommen.de.alt.netdigest abbestellst, weil du die Postings eh schon alle kennst. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Thu, Dec 23, 2004 at 01:38:53PM -0000, Ian Pratt wrote:> Interesting. Is 2.6 OpenAFS support being actively worked on? Who by?Not sure how mature it is, but there''s been a good deal of 2.6 experience reported on the openafs list; it appears to be working, at least on the client side, at least for some folks. I''m guessing we''ll see it official early in OpenAFS 1.4.X. Steve -- Stephen G. Traugott (KG6HDQ) UNIX/Linux Infrastructure Architect, TerraLuna LLC stevegt@TerraLuna.Org http://www.stevegt.com -- http://Infrastructures.Org ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Mon, Jan 03, 2005 at 06:54:18PM -0800, Steve Traugott wrote:> On Thu, Dec 23, 2004 at 01:38:53PM -0000, Ian Pratt wrote: > > Interesting. Is 2.6 OpenAFS support being actively worked on? Who by? > > Not sure how mature it is, but there''s been a good deal of 2.6 > experience reported on the openafs list; it appears to be working, at > least on the client side, at least for some folks. I''m guessing we''ll > see it official early in OpenAFS 1.4.X.It is not likely that OpenAFS 1.4 will be released before support exists for Linux 2.6. It is currently fairly well supported in the 1.3.x series, but one major feature that is lacking on Linux 2.6 is PAG support. That is currently being worked on though. Right now, most of the active Linux OpenAFS developers are working on stabilizing the Linux 2.6 support. Kris ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Hi Andrew, Just wanted to bring you up to date on where I am with blocktap -- over the holidays I got far enough to see that I need to load the blktap driver in an unstable priviledged guest with MODE_INTERCEPT_FE, and have my own userland code mmap /dev/blktap in order to talk to it. So far there seems to be enough here in what you''ve sent me for me to be able to figure out the rest as well. The first week after the holidays I was swamped -- then I got sick, and can''t seem to break out of it. I do hope to get back to this as soon as I can, and will let you know when I do. Thanks for your help so far, Steve On Thu, Dec 23, 2004 at 05:48:07AM -0800, Steve Traugott wrote:> On Thu, Dec 23, 2004 at 12:36:30PM +0000, Andrew Warfield wrote: > > I''ve got a newer and more, um, robust ;) version of the blktap stuff > > in my repository... it''s a bit tied up with some of the other device > > channel updates that we have been looking at lately though -- so it''s > > not in a state to integrate directly to the public trees. I''d imagine > > that much of this stuff should be ready to go into unstable in the > > next few weeks... hopefully along with a nettap as well. > > > > Steve, if you need the tap more urgently than this, I can likely sort > > out an interim version. If you can wait until early january though, > > that might be best. > > Thanks Andrew! I''m going to take a look at what''s in unstable first, > try to understand and play with it. I''d expect that''s going to take me > through the holidays. > > Steve > -- > Stephen G. Traugott (KG6HDQ) > UNIX/Linux Infrastructure Architect, TerraLuna LLC > stevegt@TerraLuna.Org > http://www.stevegt.com -- http://Infrastructures.Org > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xen-devel-- Stephen G. Traugott (KG6HDQ) UNIX/Linux Infrastructure Architect, TerraLuna LLC stevegt@TerraLuna.Org http://www.stevegt.com -- http://Infrastructures.Org ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It''s fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel