Re: z/Linux or zLinux - which is preferred?
On Fri, Jul 20, 2007 at 10:20:53AM -0700, Lionel Dyck wrote: > So what is the preferred way to designate Linux for zSeries - as z/Linux > or zLinux ? >From whose point of view? From the non-IBM Linux developers view it's just Linux on s/390 because s390(x) is the port name even if there have been a few rebrandings since. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Cluster File System for HA
On Tue, May 15, 2007 at 10:12:57AM -0400, David Boyes wrote: > > OpenGFS is dead, especially now that GFS is free software again. > > Good to hear. OpenGFS was a hack. Still, there are people who still use > it. I sincerly hope no ones using this code anymore, speaking as one of the founders of the OpenGFS project back in 2001. > > And OpenDFS doesn't exist, the name only every appeared in some mail > > posts regarding the free software license release of an old DCE > version. > > Beg to differ. It exists, but has not been publicized due to the general > architectural and deployment headache nastiness of DCE. I tinker with it > to support a couple of mfg customers who actually bought DCE in the > OSF/1 days and are still trying to keep it patched together. If you want > a copy, let me know. It takes some fairly stiff development skills to > make it work, however. Interesting to know. While DFS was interesting technology I doubt it makes sense to do anything major with the code base these days. It people really care it might be worth to do a modern client for the protocol from scratch, similar to what's going on with afs. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Cluster File System for HA
On Tue, May 15, 2007 at 03:48:27PM -0400, David Boyes wrote: > > A proper filesystem does not need ports to different architectures. > > If you modify this to replace "proper" with "modern", I'd be inclined to > agree. Cross-architectural purity is definitely useful, but doesn't > impact on whether the software has value or not. No, that's not what I meant. > > OpenAFS and GPFS are > > unfortuntately full of design bugs and hacks that don't let them fall > > into this category. > > At least in the case of AFS, it predates the existence of most modern > operating systems (it certainly predates the existence of Linux and any > of the assumptions thereupon), so some amount of cruft is (IMHO) > forgivable. The AFS design has held together rather well for something > of its vintage. Life in VAX-land wasn't that easy, and we should be > tolerant of the aged. There's thing that have always been wrong. Like patching syscall tables in OSes that do not explicitly support it. Or having it's own cache flushing code in assemly instead of using readily-available OS code. Or hooking into the NFS server through binary patching and overriding some of it's functionality, or dozends of other things that I could mention. > > For those using afs there is an in-kernel client > > that has seen a lot of work lately and will be support all features > > of openafs soon while fixing all these issues. There are rumors that > > it will be supported by RedHat in future releases. > > It would be nice if it tracked the openafs tree a little closer, though. > The in-kernel code has needed a lot of work so far to avoid causing > miscellaneous problems in large deployments. I don't think there is any point in tracking OpenAFS code. It's of absymal code quality, and under a strange license that wouldn't even allow to reuse a piece of good code if you managed to find it. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Cluster File System for HA
On Wed, May 09, 2007 at 12:23:36PM -0400, David Boyes wrote: > > I haven't seen a status (or statistics) recently for OCFS2. How is it > > doing? I can't remember whether it's suitable as a general purpose > > clustered file system. > > The only place I see OCFS deployed is for Oracle use. I suppose it could > be set up as a general-purpose cluster filesystem, but I haven't seen it > used that way. I has almost all features required for a normal Posix filesystem, but Oracle doesn't seem to push for that useage scenario very much. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Cluster File System for HA
On Wed, May 09, 2007 at 06:56:17AM -0400, David Boyes wrote: > Hasn't been much work on GFS recently. Since the Red Hat takeover, they've > pretty much left the 390 port lying on the ground bleeding profusely. A proper filesystem does not need ports to different architectures. OCFS2, GFS and ocfs2 fall under this category. OpenAFS and GPFS are unfortuntately full of design bugs and hacks that don't let them fall into this category. For those using afs there is an in-kernel client that has seen a lot of work lately and will be support all features of openafs soon while fixing all these issues. There are rumors that it will be supported by RedHat in future releases. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Cluster File System for HA
> > What kind of cluster filesystem is available for SLES9 / SLES10 ? > > I know there is OCFS for oracle database files, but what about non > > database > > files ? On Tue, Apr 17, 2007 at 03:21:45PM -0400, David Boyes wrote: > Lustre > OpenAFS > OpenDFS > OpenGFS > GPFS OpenGFS is dead, especially now that GFS is free software again. And OpenDFS doesn't exist, the name only every appeared in some mail posts regarding the free software license release of an old DCE version. Now when people talk about a cluster filesystem for oracle they usually mean a shared storage filesystem. Available as proper free software for that are ocfs2 and gfs in the mainline kernel tree, and both have been used for oracle clusters and the vendors promote them for that useage. Lustre is also commonly called a cluster filesystem, but works very differently, I would rather call it a massive-parallel distributed filesyste. (Open-)AFS and DFS also fall into that distributed filesystem category, but they are a lot less optimized for HPC or big commercial workloads than lustre. GPFS also falls under the shared storeage filesystem category, but it's not ported to 390 and a port would be rather non-trivial due to some of it's design decisions. The GPFS kernel code is now in theory available as free software aswell, but the IBM codedrop I have is not actually buildable, and it lacks the userspace which is very intimately tied with the kernel code. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: [PATCH 50/59] sysctl: Move utsname sysctls to their own file
On Thu, Jan 18, 2007 at 02:34:49PM -0500, Post, Mark K wrote: > Christian, > > I'm thinking that we want to have _some_ list in MAINTAINERS, just not this > one. The reason I say that is if the git390 system starts to become used by > more people, having the ability to subscribe to that list (whatever we wind > up calling it) would probably be helpful. Yes, I think someone (Martin?) should request a [EMAIL PROTECTED] list that is a more traditional development list. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: BUG: Soft Lockup detected on CPU#
On Tue, Oct 10, 2006 at 01:24:20PM +0200, Martin Schwidefsky wrote: > On Tue, 2006-10-10 at 12:14 +0200, Carsten Otte wrote: > > > The way how the soft-lockup detection works right now is broken for > > > system that utilize virtual cpus. You could argue that all zSeries > > > systems use virtualized cpu so the feature does not make sense. > > With dedicated PUs on a logical partition, and when running on raw > > iron the feature should work fine afaict. No? > > Yes, in that special case it should work. But who is using dedicated PUs > on LPAR? 1% of the installed linux systems? The best thing to do is to > disable the config option, as it is harmful for the majority of the > systems. Heiko already sent a patch. The right thing would be to disable it for virtualized systems at runtime. Especially as S/390 is not the only virtualized system these days. I wonder why no one has hit this issue with Power5 or Xen systems yet. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: [PATCH 3/3] kthread: convert the s390 qeth driver to use kthread
On Thu, Aug 24, 2006 at 04:25:27PM -0500, Serge E. Hallyn wrote: > Convert the s390 qeth driver, which can be a module, to use kthread > rather than kernel_thread, whose EXPORT_SYMBOL is deprecated. > > Compiles and boots, and dmesg shows it is in use for eth0. NACK. for the rationale see my reply to the lcs patch. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Mac Pro
On Fri, Aug 11, 2006 at 11:28:53AM -0400, Dominic Coulombe wrote: > Linux does support reading files from a HFS or HFS+ filesystem, but writing > is dangerous or unsupported - don't remember. That's definitly not true. The HFS+ driver has always been well-working and stable for writing, and the HFS driver is since it got a major rewrite shortly after the HFS+ driver was introduced. > -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: ext3 and BKL
On Fri, Aug 04, 2006 at 11:23:50AM -0400, Neale Ferguson wrote: > Reiser still makes extensive use of the BKL (Big Kernel Lock). In 2.4 ext3 > appeared to use it a lot too. What is the state of play with ext3 and BKL in > 2.6. Just looking at the source I couldn't find any references to > lock_kernel. The locks appear to be local (buffer, ext3_handler ...). I know > there were significant performance improvements shown in some benchmarks run > on 2.6 compared to those on 2.4 and also scalability improvements. The > latter indicates a lesser reliance on things like BKL. ext3 in current 2.6 mainline doesn't use the BKL anymore. The changes happen during the 2.6 series, I think 2.6.5 and thus SLES9 still used the BKL. If you care about this topic the OLS paper from Dave Chinner has some nice figures on large system scaling of different filesystems: https://ols2006.108.redhat.com/reprints/chinner-reprint.pdf -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Wed, Jul 26, 2006 at 03:04:34PM -0400, Alan Altmark wrote: > On Wednesday, 07/26/2006 at 01:27 EST, J Leslie Turriff > <[EMAIL PROTECTED]> wrote: > > Okay, now, wait; are you saying that the storage device _does_ have a > > mechanism for communicating with the Linux filesystem to determine what > > filesystem pages are still cached in main storage and have not yet been > > commited to external storage? > > No. I'm saying that an application that closes or flushes all of its open > files and then tells the filesystem "commit the filesystem to disk" (e.g. > sync) is then at a known point with respect to the dasd. It is free at > that point to kick off a flashcopy via some command or utility and start > running again. if you are doing an fsync that data is guarnateed to be on stable storage, yes. But that's not enough, because it is a) not specified where on stable storage, it could for example still be in the log of a data journaling device b) you risk sever corruption if the filesystem metadata is not in a coherent state, up to the point that you can't find your data anymore despite it beeing on stable storage. > > Alan Altmark > z/VM Development > IBM Endicott > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 ---end quoted text--- -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Wed, Jul 26, 2006 at 01:27:06PM -0500, J Leslie Turriff wrote: > Okay, now, wait; are you saying that the storage device _does_ have a > mechanism for communicating with the Linux filesystem to determine what > filesystem pages are still cached in main storage and have not yet been > commited to external storage? It doesn't. It's also not as easy as having a list of pages that need commiting. What we would need is a way for the storage device (or rather the software controlling it) to call the existing Linux lockfs functionality. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Wed, Jul 26, 2006 at 12:50:09PM -0400, Alan Altmark wrote: > You're right, however, and as we've been discussing, that these features > can be misused or misinterpreted to provide an *application*-consistent > view of the data. They don't do that. That applies to any operating > system, not just Linux. And it's not the lock/unlock features of a > filesystem that are important. Instead, the application must be able to > exert control on the filesystem in such a way that it *knows* that all > [relevant] data has been committed to disk and can say "OK. Now is a good > time to take that backup." With a transaction-oriented application the filesystem data is always coherent, if you application isn't transaction-based all hope for a coherent backup is lost. > > Properly used, these features can drastically reduce the amount of down > time needed to perform application-consistent backups. > > Alan Altmark > z/VM Development > IBM Endicott > > -- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 ---end quoted text--- -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Wed, Jul 26, 2006 at 06:21:03PM +0200, Rob van der Heij wrote: > On 7/26/06, Mark Perry <[EMAIL PROTECTED]> wrote: > > >One point not mentioned yet, is that FLASHCOPY is an asynchronous process. > >You can start a FLASHCOPY operation and it *can* return an error status > >asynchronously. 90+% of the time this is not apparent, the request is made > >and the Shark goes happily on its way. However if the request that is > >queued within the Shark has to be terminated (Resource shortages, target > >volume errors etc.) then beware! > > Unless I am terribly misinformed, it *is* an atomic operation for the > operating system. Doing it atomic is not enough. You need to put the filesystem into a coherent state first. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Wed, Jul 26, 2006 at 02:28:53PM +0200, Carsten Otte wrote: > Very interresting indeed. This pointed me to reading the > lockfs/unlockfs semantics in Linux, and I think I need to withdraw my > statement regarding flashcopy snapshots: because of the fact that > there is no lockfs/unlockfs interaction when doing flashcopy, and > because of dirty pages in the page cache during snapshot, flashcopy > will not generate a consistent snapshot. Therefore, using flashcopy on > an active volume from outside Linux is _not_ suitable for backup purposes. > > The only feasible way to get a consistent snapshot is to use > dm-snapshot from within Linux. This snapshot copy can later on be used > with a backup feature outside Linux. If you use xfs you can also put the filesystem in frozen state from userspace with the xfs_freeze utility. I know of inhouse backup tools at various companies that make use of this feature. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Tue, Jul 25, 2006 at 09:06:54AM +0800, John Summerfied wrote: > To avoid the nitpickers, let's say that David means all filesystems must > be flushed and ro. > > As I understand it, journalling (by default) logs metadata (dirctory > info) but not data. > > If you create a file, that's journalled. If you extend a file, that's > journalled. The data you write to the file are not. > > Let's say that you create a file, write 4K to it, close it. Let's say > you do a backup of the volume externally while the 4K data remains > unwritten. Note: read in "man 2 close" "A successful close does not > guarantee that the data has been successfully saved to disk." > > So now you have journalled (or comitted) metadata that says the file's > got 4K of data in it. > > But, it hasn't. In the ordinary course of events, the data gets written > to disk ans all is well. > > The same sort of thing happens when a file's updated in place, as I > expect databases commonly are. But that's not how snapshot work. When you do a snapshot the filesystem is frozen. That means: new file writers are blocked from dirtying the filesystem throug the pagecache. The filesystem block callers that want to create new transactions. Then the whole file cache is written out and the asynchronous write ahead log (journal) is written out on disk. The filesystem is in a fully consistant state. Trust me, I've implemented this myself for XFS. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Bad Linux backups
On Tue, Jul 25, 2006 at 01:22:53PM +0200, Mark Perry wrote: > I believe that several DB systems offer direct/raw I/O to avoid Linux cache > problems, and that journaling filesystems, although by default only journal > meta-data, offer mount options to journal data too. This of course comes at > a performance price, though Hans Reiser did claim that the new Resier4 FS > will journal data without the previous performance penalties. Journalled filesystems only journal buffered I/O. Direct I/O means you do direct dma operations from the storage controller to the user address space. It's physically impossible to journal. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: sharing filesystems
On Wed, Jun 28, 2006 at 11:06:14AM -0500, Dave Jones wrote: > Hi, Marian. > > I would suggest that you look into using one of the Linux file systems > that are meant to be shared by various Linux images, be they virtual > under z/VM or real on Intel hardware. > > 1) OpenAFS (the folks over at Sine Nomine http://www.sinenomine.net/ > know a lot about this one) That's a network filesystem, only one system image very actually writes to the disk. > 2) IBM's GPFS (although I don't know if this is available for zLinux yet.) It wouldn't be portable to zLinux even if people wanted it without a major rewrite because it's encodes various AIXism that make it hard to use. Besides that it's a really messy piece of junk that no one should use. > 3) RedHat's Global File System (original done by Sistina, I believe...) > http://www.redhat.com/software/rha/gfs/ that's a useable shared filesystem, yes. and 4) most importantly ocfs2 which is included in the current mainline kernel aswell as SLES9+ -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: z/Linux to p/Linux
On Thu, Jan 05, 2006 at 10:57:16AM -0500, Kielek, Samuel wrote: > > Actually, it's running on top of a stripped-down Red Hat. > > That is incorrect. ESX does not run on Red Hat or any other Linux based > OS. I think you are referring to the service console which is based off > of an older version of Red Hat (7.x). However, the service console is > not required for operation. In fact, you can shut the service console > down altogether and your guests will continue to run just fine. I think > people mistakenly think that the ESX hypervisor runs under Linux because > it uses a familiar Linux bootstrap process, but that is where the > similarity ends.. It's also reusing lots of linux code for drivers and subsystems (illegally, that is) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
On Thu, Oct 13, 2005 at 08:12:57AM +0800, John Summerfied wrote: > David Boyes wrote: > > > > >If process acquires lock on /sysfs/zvm/diag/8/lock (ie flock succeeds), > >then > >write CP command into cmdstring to prepare for call. Once parameters are > >loaded, open of /dev/diag8 and write a 1 to /dev/diag8 to execute the > > I don't understand why you would use a device for this which seems to me > is just another control function. Doesn't this function belong in sysfs too? Because sysfs exposes attributes. Everything that's a request / reponse call to some underlying layer (be it hardware or software) is fundamentally ill-suite for sysfs. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: DIAG [was: 2005-10-04 Recommended Linux on zSeries ...]
On Wed, Oct 12, 2005 at 01:13:24PM -0400, David Boyes wrote: > Given that the "Unix model" is incorporating useful concepts from Plan 9 and > other systems as fast as it can absorb them, I'd say it anticipates the > direction things are going rather nicely. Where do you think the idea behind > pseudo-filesystems like proc and sysfs came from? It certainly didn't > originate in Unix, you can be certain of that. procfs came from UNIX v8, the first research unix after the commercial variant forked. It found it's way back into the commercial UNIX and Linux world via plan9. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: catfight.
On Thu, Oct 06, 2005 at 04:24:44PM -0400, David Boyes wrote: > There is something that needs to be discussed here, though. One of the > observations early on in the project of bringing Linux to the mainframe was > a perception that the IBM Germany folks tend to prefer to implement a > solution within their environment and provide a "immaculate conception" > disclosure when it's "ready", versus the more open "here's what we had in > mind, what do you think?" approach of discussion before going off and > implementing. Some of that is definitely cultural -- my lovely German wife > exhibits this problem often...8-) -- but we've made a lot of progress on > that front from both sides. This issue seems to have slipped back into the > old model. I noticed that s390 patches seem to drop out of the thin air aswell. Fortunately nowdays the results are pretty nice. That doesn't mean everyone has to do it, in fact it's certainly not the preffered way for Linux development. > If there were problems with the cpint code (either technical or aesthetic), > it would have been helpful to have discussed them in the open and given > Neale an opportunity to fix them. Implementing another solution without > discussion is divisive, and confuses the "answer" that we give to newbies. > Multiple ways of doing things isn't always a good thing, and "choose your > favorite" isn't a good argument to give to someone who wants to be told how > to make something work, not care about the technical goodness/badness of > options. Consider the number of people who rely on the "cookbooks" in the > redbooks. Reviews take time, a _lot_ of time. I only bother review code that's not actually submitted for inclusion if there's a good reason for it. > On the other hand, there is good reason to pay attention to the discussion > of the political ramifications of the current arrangement with code > incorporation. Martin's job depends on him obeying IBM's restrictions on his > actions. Getting him fired is a dumb idea -- he's doing a nasty job to the > best of his ability, and IBM has justifiable concerns about IBM employees > approving stuff for which they don't control the provenance -- the SCO suit > is an expensive undertaking, and they don't need more of them to make things > worse. Unfortunately, those restrictions are making it difficult to > contribute useful advances, and that's causing a lot of frustration from > those of us who AREN'T IBM employees on how we can contribute useful things > and not put Martin out of work. This is _not_ a general IBM problem but a very specific problem with the S/390 division(s). The power or Intel people at IBM don't have problems like that at all. That doesn't mean it's the engineers folks in those divisions - quite contrary, I know how much they dislike it from personal talk. In either case the Linux development is structured in way that this doesn't matter. Even if Martin and others couldn't even comment on others patches other people in the linux community can and patches will go in if they're good enough. Fortunately they actually can comment on it, just not submit it for others, so this really would be a non-problem if the non-IBM S/390 community would get their ass of the chair and actually submit code. I might have been a bit harsh in the last mails, but I get really pissed when people complain about others when they're not even doing their basic homework. > I think that long-term, the answer is to place the 390 gatekeeper role > outside IBM. I don't think the gatekeeper roles on other architectures are > required to be within the company of manufacture -- I don't think Intel > insists on being the gatekeeper for Intel patches Right now we often have people associated with vendors beeing architecture maintainers where an architecture is clearly dominated by a single vendor - e.g. Tony Luck from Intel for IA64, the ozlabs people for 64bit powerpc, Ralf Baechle for mips and a few more. It's not nessecarily so but makes a lot of sense in general. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
Stop bitching. Your problem is that you even think about such non-problems instead of getting work done. Submit patches to lkml and forget about all the legal crap. Or as Theo de Raat would say it: "Shut up and code" -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: 2005-10-04 Recommended Linux on zSeries code drop to developerWorks
On Wed, Oct 05, 2005 at 11:14:42AM -0400, Post, Mark K wrote: > Because IBM's lawyers forbids IBM employees to "sign off" on code that > they did not write. At the moment, Martin Schwidefsky of IBM is > considered the architecture maintainer for mainframe Linux. This makes > him the only person from which Linus and Andrew Morton will accept > mainframe-related patches. Neale Ferguson, Martha McConaghy, myself, > and a some IBMers have been working to try to get IBM legal to allow > Martin to at least comment on patches that non-IBM employees submit. So > far that has not been forthcoming. As a result, it looks like we're > going to have to do an end-run around IBM legal, and submit patches to > Andrew and Linus directly, while explaining why its being done. Neale > was getting some feedback from some of the developers to make his > version more acceptable in terms of coding style, etc., but hasn't > gotten far enough along to actually submit it. That's bullshit. I've many ACKs for my patches touching arch/s390 from IBM people. Nevermding, cpint is not only doing the split wrong, it's also utter crap code. I haven't actually looked at the replacement, but I doubt it can be worse. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: OT: but so funny.
On Fri, Sep 09, 2005 at 01:36:31PM -0500, McKown, John wrote: > FSVO "funny". Is Microsoft idiotic or egotistical beyond belief? > > http://esr.ibiblio.org/index.php?p=208 > > Eric S. Raymond gets a job offer from Microsoft. And it read like a form > letter. I got the same one, as did various other kernel hackers, looks they used a spambot with some opensource mailinglist or newsgroup a input. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Java 1.5 on Linux for z/Series
On Wed, Jun 29, 2005 at 01:24:03PM -0400, Neale Ferguson wrote: > About %#$& time! We can finally get rid of the compat libraries due to > the use of the old ABI in the JVM. New C++ programs that use the JNI > will now be able to work. Use gcj or kaffee and get that today ;-) -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: 2005-04-28 Recommended Linux on zSeries code drop to developerWorks
On Thu, Apr 28, 2005 at 03:47:20PM +0200, Gerhard Hiller wrote: > > New OCOs for Red Hat: > > - tape_3590 for Red Hat Enterprise Linux AS (v. 4) > (31-bit and 64-bit) kernel 2.6.9-5.0.5.EL (2005-04-19) > - tape_3590 for Red Hat Enterprise Linux AS (v. 3) > (31-bit and 64-bit) kernel 2.4.21-27.0.4.EL (2005-04-22) Btw, any plans to finally opensource the tape_3590 driver? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: VMware vs. VM
On Fri, Dec 10, 2004 at 09:56:34AM -0800, Steve Shomaker wrote: > VMware ESX Server runs on bare metal. Actually it includes various parts of the Linux Kernel, thus violating the Copyrights of us Linux Kernel Copyright holders. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Big Iron change
> Ah, but the question was, does he have to reinstall his penguins. And > the answer is "probably not". They will get faster because the > hardware is faster, but reinstalling the Linux image itself probably > won't help. At least not if you install it with all the same > parameters. And you can easily install a new kernel image without scrapping the whole system setup. It's just installing another rpm and switching a flag to make it booted by default. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: cmsfs on 2.6?
On Tue, Nov 23, 2004 at 12:34:35PM -0500, Michael MacIsaac wrote: > Does the cmsfs package (1.1.8) build on the 2.6 kernel (SLES9)? I got an > error from ./configure: > cmsfssed.sh: this release of Linux is not supported! Where is that package from? Might be worth to massage into a proper 2.6 filesystem driver. Anybody's got some test fs images? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: [PATCH] Add key management syscalls to non-i386 archs
On Wed, Oct 20, 2004 at 10:50:27AM -0700, Andrew Morton wrote: > Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > > > > Hi Linus, Andrew, > > > > > > The attached patch adds syscalls for almost all archs (everything barring > > > m68knommu which is in a real mess, and i386 which already has it). > > > > > > It also adds 32->64 compatibility where appropriate. > > > > Umm, that patch added the damn multiplexer that had been vetoed multiple > > times. Why did this happen? > > Fifteen new syscalls was judged excessive and the keyfs interface was > judged slow and bloaty. Maybe 15 syscalls just means the API is goddamn awfull and we certainly shouldn't merge it as-is. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: [PATCH] Add key management syscalls to non-i386 archs
> Hi Linus, Andrew, > > The attached patch adds syscalls for almost all archs (everything barring > m68knommu which is in a real mess, and i386 which already has it). > > It also adds 32->64 compatibility where appropriate. Umm, that patch added the damn multiplexer that had been vetoed multiple times. Why did this happen? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Search script
On Fri, Oct 01, 2004 at 11:06:52AM -0400, Mark D Pace wrote: > Does some have a script they could share that would do the following > Search through a list of filesie. *.conf > Look for a particular string ie. 'virtual' > If the string is found I would like to display the line and filename that > contained that line. > > I can do part of that by doing cat *.conf |grep stringbut that only > displays the line, not the file in which it was found. > Can someone help me out with the file name part? GNU grep has an -r option to search recursively. E.g. grep -r foobar /etc -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: GPFS
On Fri, Jul 23, 2004 at 11:38:53AM -0400, Jim Elliott wrote: > > If I remember correctly, Oracle plans on releasing OCFS for > > Linux on zSeries > > However, it should be noted at OCFS is limited to being used for > Oracle database files. OCFS is NOT a general purpose file system. Not true for OCFS2 anymore. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: TurboLinux Enterprise Server 8
On Thu, May 06, 2004 at 10:14:06AM -0400, Scully, William P wrote: > A fellow at our site downloaded the ISOs for TurboLinux ES 8 and gave a > copy to me. They are named something like: > > TurboLinux-Server-8-zseries-CDn.iso > > Where "n" varies 1->5. When I mount these via a loop-back they appear > -exactly- the same as SuSE Linux Enterprise Server 8, right down to the > readme file. Is someone pulling my leg here? I know TurboLinux web > site says that TLES8 is based on United Linux, but are the merely > redistributing the SuSE materials? That what UnixtedLinux was about - allowing the other partners to resell a rebranded SuSE product, maybe with an additional 'value-add' CD. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Red Hat acquires Sistana (and LVM)
On Fri, Jan 09, 2004 at 02:46:49PM -0600, Chris Cox wrote: > It's very likely that Red Hat will make it GPL unless > there is something inside the thing that would prevent > that (even then, it just means it'll take a bit longer). > > Do you know yet, Alan? Alan (and another kernel hacker from RedHat) worked with me on fixing up the last GFS version before they went closed source, and unless the GFS code is in a much better shape than at that time (which I strongly doubt) it would be a shame for redhat to release that code and probably immediately followed by a few remote exploits for their 'enterprise' product.. But from the PR speak it seems they will opensource it and maybe the pear review will actually make it a good product some day. Note that OpenGFS still isn't dead and has made some nice progress, like support for the IBM distributed lock manager (so the single point of failure in Sistina's GFS which is completly untolerable for HA enviroments is gone) and a first cut of support for the Linux 2.6 kernel. But even OpenGFS still needs lots of work. We'll see what RedHat will do with their new engineering ressource sooner or later I'll guess.
Re: OT: (GPL discussion)
On Tue, Jan 06, 2004 at 02:34:23PM -0600, Jay Maynard wrote: > On Tue, Jan 06, 2004 at 03:08:56PM -0500, David Andrews wrote: > > The OS X kernel is "Darwin", itself based on the Mach microkernel. > > Supposedly there is a good deal of higher-level BSD code in there, and > > it wouldn't surprise me much to find out that FreeBSD was the source. > > But it is nevertheless incorrect to say that OS X is FreeBSD. > > No, it's not. *BSD on the PowerPC has always been Mach-based. If you wish > to be complete, you can mention the Mach roots of the system, but Darwin is > quite firmly based on FreeBSD. Nah. Neither the free, net nor openbsd ppc ports are mach-based. And OS X is a NeXt derivate that started on m68k :) And trust me as someone who's looked through the darwin kernel code, it's pretty different from the free bsds. There's quite a bunch of code borrowed from various bsds (mostly filesystems and networking), but that's quite often from really old (4.2/4.3BSD) release and doesn't really resembles what's in the modern free bsds.
Re: Anyone Nagios? (GPL discussion)
On Tue, Jan 06, 2004 at 11:52:24AM -0800, Fargusson.Alan wrote: > I think Apple stated that they went with FreeBSD because they don't like the GPL. > The reason that they are contributing back to FreeBSD is because they were not > getting support from OSS developers. Now they are. The GPL may not be seen as > business friendly, but it does work. What is Apple contribtuing back to the free bsds? apple seems to stick their strange mpl-like license on all their 'open-source' code, so it's rather useless to the BSDs. The whole Apple opensource story sounds more like a big marketing gag to me.
Re: Anyone Nagios? (GPL discussion)
On Tue, Jan 06, 2004 at 10:33:41AM -0800, Fargusson.Alan wrote: > BTW: I am not sure that X counts, since Xfree86 is not based on X source code. Huh? XFree is of course based on the X11 reference implementation.
Re: Anyone Nagios?
On Mon, Jan 05, 2004 at 12:52:46PM -0500, David Andrews wrote: > Jay is right insofar that -- practically speaking -- you can only sell > your code for more than your distribution cost one time. Eventually > somebody like CheapBytes will come along and redistribute your GPLed > code for next to nothing. Why would you give the software software you just bought for lots of money freely away?
Re: Problems with sysstat package on Debian
On Fri, Jul 18, 2003 at 11:22:37AM -0600, Nakagawa, Robert wrote: > /proc/partitions info > major minor #blocks name > > 94 0144 dasd/0150/disc > 94 11439904 dasd/0150/part1 > 94 4 10 dasd/0151/disc > 94 5 9 dasd/0151/part1 Hmm, with CONFIG_BLK_STATS=y you should really get I/O statistics here.
Re: Problems with sysstat package on Debian
On Fri, Jul 18, 2003 at 01:47:38PM -0500, Adam Thornton wrote: > On Fri, 2003-07-18 at 13:37, Lucius, Leland wrote: > > As I mentioned before, I'm running SuSE, but if no one else has any other > > suggestions, I can certainly pull down the Debian kernal source to see if > > there's anything obvious. (SuSE doesn't have the CONFIG_DISK_STAT option.) > > Nor Debian 2.4.21. Sorry, it's actually CONFIG_BLK_STATS (or CONFIG_BLK_STAT for some suse releases)
Re: Problems with sysstat package on Debian
On Fri, Jul 18, 2003 at 08:37:55AM -0600, Hodge, Robert L wrote: > I'm having problems with the sysstat package on the Debian 3.01 > distribution. "sar -b" is returning all zeroes for disk activity and > "iostat" is not reporting anything for disk. It looks like iostat is not > finding any disks. I've searched the archives of this list and other > lists with no positive results. I've done numerous web searches with no > results. I've upgraded the sysstat package to 4.1.2 from 4.0.4 with no > resolution to the problem. I've upgraded the Linux kernel to 2.4.21 from > 2.4.17 with no resolution to the problem. Do you have CONFIG_DISK_STATS enabled in the kernel? Please post the output of /proc/stat and /proc/partitions on your system.
[PATCH] xattr syscalls missing on s390/s390x
Fromn 2.4 s390/s390x doesn't implement the xattr syscalls yet. p.s. any chance s390 will at least be in a compilable shape when 2.4.21 is release? --- 1.14/arch/s390/kernel/entry.S Tue Jul 30 13:27:40 2002 +++ edited/arch/s390/kernel/entry.S Wed Feb 12 13:13:37 2003 @@ -558,18 +558,18 @@ .long sys_fcntl64 .long sys_ni_syscall .long sys_ni_syscall - .long sys_ni_syscall/* 224 - reserved for setxattr */ - .long sys_ni_syscall/* 225 - reserved for lsetxattr */ - .long sys_ni_syscall/* 226 - reserved for fsetxattr */ - .long sys_ni_syscall/* 227 - reserved for getxattr */ - .long sys_ni_syscall/* 228 - reserved for lgetxattr */ - .long sys_ni_syscall/* 229 - reserved for fgetxattr */ - .long sys_ni_syscall/* 230 - reserved for listxattr */ - .long sys_ni_syscall/* 231 - reserved for llistxattr */ - .long sys_ni_syscall/* 232 - reserved for flistxattr */ - .long sys_ni_syscall/* 233 - reserved for removexattr */ - .long sys_ni_syscall/* 234 - reserved for lremovexattr */ - .long sys_ni_syscall/* 235 - reserved for fremovexattr */ + .long sys_setxattr + .long sys_lsetxattr/* 225 */ + .long sys_fsetxattr + .long sys_getxattr + .long sys_lgetxattr + .long sys_fgetxattr + .long sys_listxattr/* 230 */ + .long sys_llistxattr + .long sys_flistxattr + .long sys_removexattr + .long sys_lremovexattr + .long sys_fremovexattr /* 235 */ .long sys_gettid .long sys_tkill .rept 255-237 --- 1.13/arch/s390x/kernel/entry.S Tue Jul 30 13:27:40 2002 +++ edited/arch/s390x/kernel/entry.SWed Feb 12 13:13:35 2003 @@ -591,18 +591,18 @@ .long SYSCALL(sys_ni_syscall,sys32_fcntl64_wrapper) .long SYSCALL(sys_ni_syscall,sys_ni_syscall) .long SYSCALL(sys_ni_syscall,sys_ni_syscall) - .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 224 - reserved for setxattr */ - .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 225 - reserved for lsetxattr */ - .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 226 - reserved for fsetxattr */ - .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 227 - reserved for getxattr */ - .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 228 - reserved for lgetxattr */ - .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 229 - reserved for fgetxattr */ - .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 230 - reserved for listxattr */ - .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 231 - reserved for llistxattr */ - .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 232 - reserved for flistxattr */ - .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 233 - reserved for removexattr */ - .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 234 - reserved for lremovexattr */ - .long SYSCALL(sys_ni_syscall,sys_ni_syscall) /* 235 - reserved for fremovexattr */ + .long SYSCALL(sys_setxattr,sys32_setxattr_wrapper) + .long SYSCALL(sys_lsetxattr,sys32_lsetxattr_wrapper) /* 225 */ + .long SYSCALL(sys_fsetxattr,sys32_fsetxattr_wrapper) + .long SYSCALL(sys_getxattr,sys32_getxattr_wrapper) + .long SYSCALL(sys_lgetxattr,sys32_lgetxattr_wrapper) + .long SYSCALL(sys_fgetxattr,sys32_fgetxattr_wrapper) + .long SYSCALL(sys_listxattr,sys32_listxattr_wrapper) /* 230 */ + .long SYSCALL(sys_llistxattr,sys32_llistxattr_wrapper) + .long SYSCALL(sys_flistxattr,sys32_flistxattr_wrapper) + .long SYSCALL(sys_removexattr,sys32_removexattr_wrapper) + .long SYSCALL(sys_lremovexattr,sys32_lremovexattr_wrapper) + .long SYSCALL(sys_fremovexattr,sys32_fremovexattr_wrapper)/* 235 */ .long SYSCALL(sys_gettid,sys_gettid) .long SYSCALL(sys_tkill,sys_tkill) .rept 255-237 --- 1.4/arch/s390x/kernel/wrapper32.S Tue Feb 5 15:10:15 2002 +++ edited/arch/s390x/kernel/wrapper32.SWed Feb 12 13:13:36 2003 @@ -1091,3 +1091,95 @@ llgtr %r3,%r3 # struct stat64 * llgfr %r4,%r4 # long jg sys32_fstat64 # branch to system call + + .globl sys32_setxattr_wrapper +sys32_setxattr_wrapper: + llgtr %r2,%r2 # char * + llgtr %r3,%r3 # char * + llgtr %r4,%r4 # void * + llgfr %r5,%r5 # size_t + lgfr%r6,%r6 # int + jg sys_setxattr + + .globl sys32_lsetxattr_wrapper +sys32_lsetxattr_wrapper: + llgtr %r2,%r2 # char * + llgtr %r3,%r3 # char * + llgtr %r4,%r4 # void
