Linux Compatible USB Adapter Recommendations? [OT]
I'm looking to buy a wireless USB adapter that I can plug into a Fedora 8 box. The main feature I want it to be able to stick it in and have it just work. No custom kernel compiles. If it had 802.11n that would be a plus. So - what "just works" with Linux? Thanks in advance. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux Compatible USB Adapter Recommendations? [OT]
I'm looking to buy a wireless USB adapter that I can plug into a Fedora 8 box. The main feature I want it to be able to stick it in and have it just work. No custom kernel compiles. If it had 802.11n that would be a plus. So - what just works with Linux? Thanks in advance. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel friendly chipsets - video drivers - nVidia vs. AMD 690G
I have a question about chipset compatibility for video. I have an Asus motherboard with integrated graphics using the nVidia chipset and a large monitor (1680x1050) and eventually got it to work. I have a new Asus motherboard that I'm thinking about using as a replacement that uses the new AMD 690G chipset. I'm thinking of using it in the workstation and using the nVidia board on a colo machine. My question - how friendly is the video drivers in Linux with the AMD690G chipset? Is it going to work in 1680x1050 mode easily or should I stick with nVidia? Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kernel friendly chipsets - video drivers - nVidia vs. AMD 690G
I have a question about chipset compatibility for video. I have an Asus motherboard with integrated graphics using the nVidia chipset and a large monitor (1680x1050) and eventually got it to work. I have a new Asus motherboard that I'm thinking about using as a replacement that uses the new AMD 690G chipset. I'm thinking of using it in the workstation and using the nVidia board on a colo machine. My question - how friendly is the video drivers in Linux with the AMD690G chipset? Is it going to work in 1680x1050 mode easily or should I stick with nVidia? Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Brennan Ashton <[EMAIL PROTECTED]> wrote: > While i highly support innovation, until i see a > well layed out > structure of what exactly you are looking for i have > a hard time > expressing any view that are meaningful, could you > create some kind of > wiki or summery email (if this is really this > important to you) most > of us are lazy and have better things to do, make it > easy for us. > A) Create a list of the current problems or just > inefficiencies in > the current system. > B) Create a list of all the points that make up > your view of a good > file system. > C) Cross the two lists showing how your idea would > fix the current problems. > > I am not saying that the current way is the right or > wrong way, just > that i think you have organised your ideas as if you > are thinking out > loud by email (which is ok by me, just stop the > direct attacks if you > are). > I agree that every company and program gets caught > in a rut, that does > not conform to changing markets and technology, > especially if it was > at one time a success, IBM, Microsoft, Apple, Sun, > American Auto > Industry to name a few. These are also example > companies that have > gotten the idea that what they do might not be right > way and have made > some attempt to step back (some more successfully > than others) or face > loss in market share. > Just remember a key point when rethinking something > as key as a file > system, while your new battery may be much more > efficient than my old > AA, i want it to work with my old flashlights too > (and no aftermarket > refit kit). > Should the surroundings be modified for the target, > or the target > modified for the surroundings? > Your little rants about VI and rm are not helpful, > if these programs > were so bad then why have they survived. Linux is on > hell of a project > to be put together, sorry but innovation did come > from people using VI > and Emacs. btw i highly recommend the command man, > you should try it. > -- > Brennan Ashton > Bellingham, Washington > > "The box said, 'Requires Windows 98 or better'. So I > installed Linux" > What's the point? People are openly hostile to new ideas here. I started out nice and laid out my ideas and you have a bunch of morons who attack anything new. At least finally someone fixed the RM problem. Look at the reality of the situation. Linux is free and yey it can't compete with operating systems that are paid for. Maybe the reason is that when someone point out the something is broken all yopu get is justification and excuses and insults. Read the thread from the beginning and you'll see that I started out that way. If you attack people who are pointing out flaws and making suggestions then people will stop pointing out flaws and making suggestions. Think about it. Why did it take 20 years for Linux to fix the RM problem? If you type RM * you expect the files to be gone, not some stupid error that I'm trying to delete too many files. So who's fault is that? I say it's a problem with Linux culture. If something is broken you have to justify it instead of fixing it. If developers take that kind of attitude then progress stops. You guys are trying to may the RM problem MY FAULT because I didn't say it nicely. We'll it doesn't have to be said nicely. If something is broken then it needs fixed regardless of who and how it is pointed out. A BUG is a BUG is a BUG. You fix bugs, not make excuses and try to explain it away. If you went up to any computer user and asked them if when they type "rm *" that they expect the files to be deleted they will say "yes". Yet in the Linux work the command doesn't work. And it's not like it breaks after MILLIONS of files. It breaks on just a few thousand files, if that. So wat does it tell you when something like this is left broken for so long? What it tells me is that the development process is broken. My rant on VI is to make a point. That point being that when you use an editor that totally sucks then it's going to cause you to write code that sucks. It going to lower your standards. It's going to create a culture where poorly done work is considered acceptable. When you use an editor as poor as vi then the idea that rm * doesn't work becomes acceptable and justifiable, as demonstrated here by people who ACTUALLY DEFENDED IT. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Brennan Ashton [EMAIL PROTECTED] wrote: While i highly support innovation, until i see a well layed out structure of what exactly you are looking for i have a hard time expressing any view that are meaningful, could you create some kind of wiki or summery email (if this is really this important to you) most of us are lazy and have better things to do, make it easy for us. A) Create a list of the current problems or just inefficiencies in the current system. B) Create a list of all the points that make up your view of a good file system. C) Cross the two lists showing how your idea would fix the current problems. I am not saying that the current way is the right or wrong way, just that i think you have organised your ideas as if you are thinking out loud by email (which is ok by me, just stop the direct attacks if you are). I agree that every company and program gets caught in a rut, that does not conform to changing markets and technology, especially if it was at one time a success, IBM, Microsoft, Apple, Sun, American Auto Industry to name a few. These are also example companies that have gotten the idea that what they do might not be right way and have made some attempt to step back (some more successfully than others) or face loss in market share. Just remember a key point when rethinking something as key as a file system, while your new battery may be much more efficient than my old AA, i want it to work with my old flashlights too (and no aftermarket refit kit). Should the surroundings be modified for the target, or the target modified for the surroundings? Your little rants about VI and rm are not helpful, if these programs were so bad then why have they survived. Linux is on hell of a project to be put together, sorry but innovation did come from people using VI and Emacs. btw i highly recommend the command man, you should try it. -- Brennan Ashton Bellingham, Washington The box said, 'Requires Windows 98 or better'. So I installed Linux What's the point? People are openly hostile to new ideas here. I started out nice and laid out my ideas and you have a bunch of morons who attack anything new. At least finally someone fixed the RM problem. Look at the reality of the situation. Linux is free and yey it can't compete with operating systems that are paid for. Maybe the reason is that when someone point out the something is broken all yopu get is justification and excuses and insults. Read the thread from the beginning and you'll see that I started out that way. If you attack people who are pointing out flaws and making suggestions then people will stop pointing out flaws and making suggestions. Think about it. Why did it take 20 years for Linux to fix the RM problem? If you type RM * you expect the files to be gone, not some stupid error that I'm trying to delete too many files. So who's fault is that? I say it's a problem with Linux culture. If something is broken you have to justify it instead of fixing it. If developers take that kind of attitude then progress stops. You guys are trying to may the RM problem MY FAULT because I didn't say it nicely. We'll it doesn't have to be said nicely. If something is broken then it needs fixed regardless of who and how it is pointed out. A BUG is a BUG is a BUG. You fix bugs, not make excuses and try to explain it away. If you went up to any computer user and asked them if when they type rm * that they expect the files to be deleted they will say yes. Yet in the Linux work the command doesn't work. And it's not like it breaks after MILLIONS of files. It breaks on just a few thousand files, if that. So wat does it tell you when something like this is left broken for so long? What it tells me is that the development process is broken. My rant on VI is to make a point. That point being that when you use an editor that totally sucks then it's going to cause you to write code that sucks. It going to lower your standards. It's going to create a culture where poorly done work is considered acceptable. When you use an editor as poor as vi then the idea that rm * doesn't work becomes acceptable and justifiable, as demonstrated here by people who ACTUALLY DEFENDED IT. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
--- Paolo Ornati <[EMAIL PROTECTED]> wrote: > On Sun, 19 Aug 2007 06:22:37 -0700 (PDT) > Marc Perkel <[EMAIL PROTECTED]> wrote: > > > 20 years, a million programmers, tens of millions > of > > users and RM is BROKEN. Am I the only one who has > a > > problem with this? If so - I'm normal - and Linux > is a > > cult. > > > Fixed in 2.6.23-rc (and not just for "rm"): > > commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba > Author: Ollie Wild <[EMAIL PROTECTED]> > Date: Thu Jul 19 01:48:16 2007 -0700 > > mm: variable length argument support > > Remove the arg+env limit of MAX_ARG_PAGES by > copying the strings > directly from the old mm into the new mm. > [...] > > -- > Paolo Ornati > Linux 2.6.23-rc3-g2a677896-dirty on x86_64 > Good man! Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail=graduation+gifts=bz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
--- Willy Tarreau <[EMAIL PROTECTED]> wrote: > On Sun, Aug 19, 2007 at 09:15:22AM +0200, Jiri Slaby > wrote: > > Marc Perkel napsal(a): > > > Let me give you and example of the difference > between > > > Linux open source world brain damaged thinking > and > > > what it's like out here in the real world. > > > > > > Go to a directory with 10k files and type: > > > > > > rm * > > > > > > What do you get? > > > > > > /bin/rm: Argument list too long > > > > What does this have to do with rm command? > > Nothing, and no more with linux development. Marc > confuses shell and rm. > Under DOS, when he types "del *", the shell calls > the builtin function > "del" and passes it only one argument "*". The del > function is then > responsible for iterating through the files using > getfirst/getnext. > > This is also why mostly only builtin shell commands > support "*", while > most external commands do not support it, since they > have to re-implement > the same code to iterate through the files (try > "debug c*.com", it will > not work). > > Under unix, the shell resolves "*" and passes the > 1 file names to > the "rm" command. Now, execve() may fail because > 1 names in arguments > can require too much memory. That's why find and > xargs were invented! > > The solution is easy : find . -maxdepth 1 | xargs rm > > So this has nothing to do with rm, nor with rm being > open-source, and > even less with rm being written with vi, and Marc's > rant is totally > wrong and off-topic. Maybe he was drunk when > posting, or maybe someone > used his keyboard to make him look like a complete > fool. Or maybe he > really is. > > Willy > (please do not follow up on this OT thread, > responses to /dev/null) > The important point that you are missing here is that the Linux world is willing to live with an rm command that is broken and the Windows and DOS world isn't. This isn't about the rm command it's about programming standards. It's about that the Linux community isn't committed to getting it right. Just like my thinking outside the box thread when I try to say "this is broken" people don't go fix it. Instead I get an explanation why Linux isn't capable of having an rm command that will delete an unlimited number of files. I bet there are Microsoft people out there laughing at this. THINK ABOUT IT PEOPLE !!! 20 years, a million programmers, tens of millions of users and RM is BROKEN. Am I the only one who has a problem with this? If so - I'm normal - and Linux is a cult. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
--- Jiri Slaby <[EMAIL PROTECTED]> wrote: > Marc Perkel napsal(a): > > Let me give you and example of the difference > between > > Linux open source world brain damaged thinking and > > what it's like out here in the real world. > > > > Go to a directory with 10k files and type: > > > > rm * > > > > What do you get? > > > > /bin/rm: Argument list too long > > What does this have to do with rm command? > See what I mean? Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
--- [EMAIL PROTECTED] wrote: > On Sunday 19 August 2007, Marc Perkel wrote: > > > > Let me give you and example of > > > > > brain damaged thinking > > > > > out here in the real world. > > > I tried Peyote once about 25 years ago and it was > > fantastic. > > Sounds like it hasn't worn off yet. Afreed. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
--- Al Viro <[EMAIL PROTECTED]> wrote: > On Sat, Aug 18, 2007 at 10:20:34PM -0700, Marc > Perkel wrote: > > Let me give you and example of the difference > between > > Linux open source world brain damaged thinking and > > what it's like out here in the real world. > > [snip] > > Marc, why don't you do the obvious thing and hire > Jeff Merkey? > He used to work on netware kernel, you are a netware > fanboy... > Hell, he might even share - his peyotl for whatever > you are on; > it certainly has... intriguing effects, so who knows > - maybe the > mix will give the right kind of out-of-box > experience for you ;-) > hm . So if you take Peyote then you think of things like "rm *" should delete all the files in a folder and if you're not on drugs then del from DOS being better than rm in Linux is OK. For what it's worth. I agree it seems to be that way. I tried Peyote once about 25 years ago and it was fantastic. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
--- Al Viro [EMAIL PROTECTED] wrote: On Sat, Aug 18, 2007 at 10:20:34PM -0700, Marc Perkel wrote: Let me give you and example of the difference between Linux open source world brain damaged thinking and what it's like out here in the real world. [snip] Marc, why don't you do the obvious thing and hire Jeff Merkey? He used to work on netware kernel, you are a netware fanboy... Hell, he might even share - his peyotl for whatever you are on; it certainly has... intriguing effects, so who knows - maybe the mix will give the right kind of out-of-box experience for you ;-) hm . So if you take Peyote then you think of things like rm * should delete all the files in a folder and if you're not on drugs then del from DOS being better than rm in Linux is OK. For what it's worth. I agree it seems to be that way. I tried Peyote once about 25 years ago and it was fantastic. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
--- [EMAIL PROTECTED] wrote: On Sunday 19 August 2007, Marc Perkel wrote: Let me give you and example of snip brain damaged thinking snip out here in the real world. I tried Peyote once about 25 years ago and it was fantastic. Sounds like it hasn't worn off yet. Afreed. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
--- Jiri Slaby [EMAIL PROTECTED] wrote: Marc Perkel napsal(a): Let me give you and example of the difference between Linux open source world brain damaged thinking and what it's like out here in the real world. Go to a directory with 10k files and type: rm * What do you get? /bin/rm: Argument list too long What does this have to do with rm command? See what I mean? Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
--- Willy Tarreau [EMAIL PROTECTED] wrote: On Sun, Aug 19, 2007 at 09:15:22AM +0200, Jiri Slaby wrote: Marc Perkel napsal(a): Let me give you and example of the difference between Linux open source world brain damaged thinking and what it's like out here in the real world. Go to a directory with 10k files and type: rm * What do you get? /bin/rm: Argument list too long What does this have to do with rm command? Nothing, and no more with linux development. Marc confuses shell and rm. Under DOS, when he types del *, the shell calls the builtin function del and passes it only one argument *. The del function is then responsible for iterating through the files using getfirst/getnext. This is also why mostly only builtin shell commands support *, while most external commands do not support it, since they have to re-implement the same code to iterate through the files (try debug c*.com, it will not work). Under unix, the shell resolves * and passes the 1 file names to the rm command. Now, execve() may fail because 1 names in arguments can require too much memory. That's why find and xargs were invented! The solution is easy : find . -maxdepth 1 | xargs rm So this has nothing to do with rm, nor with rm being open-source, and even less with rm being written with vi, and Marc's rant is totally wrong and off-topic. Maybe he was drunk when posting, or maybe someone used his keyboard to make him look like a complete fool. Or maybe he really is. Willy (please do not follow up on this OT thread, responses to /dev/null) The important point that you are missing here is that the Linux world is willing to live with an rm command that is broken and the Windows and DOS world isn't. This isn't about the rm command it's about programming standards. It's about that the Linux community isn't committed to getting it right. Just like my thinking outside the box thread when I try to say this is broken people don't go fix it. Instead I get an explanation why Linux isn't capable of having an rm command that will delete an unlimited number of files. I bet there are Microsoft people out there laughing at this. THINK ABOUT IT PEOPLE !!! 20 years, a million programmers, tens of millions of users and RM is BROKEN. Am I the only one who has a problem with this? If so - I'm normal - and Linux is a cult. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The vi editor causes brain damage
--- Paolo Ornati [EMAIL PROTECTED] wrote: On Sun, 19 Aug 2007 06:22:37 -0700 (PDT) Marc Perkel [EMAIL PROTECTED] wrote: 20 years, a million programmers, tens of millions of users and RM is BROKEN. Am I the only one who has a problem with this? If so - I'm normal - and Linux is a cult. Fixed in 2.6.23-rc (and not just for rm): commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba Author: Ollie Wild [EMAIL PROTECTED] Date: Thu Jul 19 01:48:16 2007 -0700 mm: variable length argument support Remove the arg+env limit of MAX_ARG_PAGES by copying the strings directly from the old mm into the new mm. [...] -- Paolo Ornati Linux 2.6.23-rc3-g2a677896-dirty on x86_64 Good man! Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mailp=graduation+giftscs=bz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
The vi editor causes brain damage
Let me give you and example of the difference between Linux open source world brain damaged thinking and what it's like out here in the real world. Go to a directory with 10k files and type: rm * What do you get? /bin/rm: Argument list too long If you map a network drive in DOS and type: del * It works. That's the problem with the type of thinking in the open source world. Why can DOS delete an infinite number of files and rm can't? Because rm was written using the "vi" editor and it causes brain damage and that's why after 20 years rm hasn't caught up with del. Before everyone gets pissed off and freaks out why don't you ponder the question why rm won't delete all the files in the directory. If you can't grasp that then you're brain damaged. Think big people. Say NO to vi! Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
No Al, there isn't any shortage of arrogance here. Let me try to repeat what I'm talking about as simply as I can. First - I'm describing a kind of functionality and suggesting Linux should have it. I know a lot of it can be done because much of what I'm suggesting is already working in Windows and Netware. I'm not the one who's going to code it. I'm just saying that it would be nice if Linux had the functionality of other operating systems - and - take it to the next level - match it and do even better. As to thinking outside the box, what I'm proposing is outside the box relative to Linux. It's not as original as compared to Windows or Netware which is even better. The idea is that Linux is lacking features that other OSs have. What I'm suggesting is that Linux not only match it but to create an even more powerful rights layer that is more powerful than the rest and I'm outlining a concept in the hopes that people would get excited about the concept and want to build on the idea. I'm just telling you what I'd like to see. I'm not going to code it. So I'm only going to talk about what is possible. How it's done will be up to any programmers who might be inspired by the idea. If no one is inspired the Linux will continue to be in last place when it comes to file system features relating to fine grain permissions. In Linux, for example, users are allowed to delete files that they are prohibited from reading or writing. In Netware if a user can't read or write to the file they won't even be able to see that the file exists, let alone delete it. In Netware I can move a directory tree into another tree and the objects that have rights in the other tree will have rights to all the new files without having to run utilities on the command line to recursively change the permission afterwards. The point - Linux isn't going to move forward and catch up unless there is a fundamental change in the thinking behind Linux permissions. There is a cultural lack of innovation here. I discussed this with Andrew Morton and he made some suggestions but there's real hostility towards new concepts here. Something I don't understand. At some point Linux needs to grow beyond just being an evolved Unix clone and that's not going to happen if you don't think differently. I still believe that the VI editor causes brain damage. :) Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett <[EMAIL PROTECTED]> wrote:
> On Aug 17, 2007, at 15:01:48, Phillip Susi wrote:
> > [EMAIL PROTECTED] wrote:
> >> It will become even *more* of a "not that common"
> if the lock will
> >> block moves and ACL changes *across the
> filesystem* for
> >> potentially *minutes* at a time.
> >
> > It will not take anywhere NEAR minutes at a time
> to update the in
> > memory dentries, more like 50ms.
>
> One last comment:
>
> 50ms to update in-memory dentries would be FRIGGING
> TERRIBLE!!!
> Using Perl, an interpreted language, the following
> script takes 3.39s
> to run on one of my lower-end systems:
>
> for (0 .. 1) {
> mkdir "a-$_";
> mkdir "b-$_";
> rename "a-$_", "b-$_";
> }
>
> It's not even deleting things afterwards so it's
> populating a
> directory with ten thousand entries. We can easily
> calculate
> 10,000/3.39 = 2,949 entries per second, or 0.339
> milliseconds per entry.
>
> When I change it to rmdir things instead, the
> runtime goes down to
> 2.89s == 3460 entries/sec == 0.289 milliseconds per
> entry.
>
> If such a scheme even increases the overhead of a
> directory rename by
> a hundredth of a millisecond on that box it would
> easily be a 2-3%
> performance hit. Given that people tend to kill for
> 1% performance
> boosts, that's not likely to be a good idea.
>
> Cheers,
> Kyle Moffett
>
>
What I suggested was a concept of a new way to look at
a file system. What you are arguing here is why it
wouldn't work based on your theories as to how such a
file system would be implemented. In attacking how
slow you think it might be you are making assumptions
that wouldn't apply to how this would be implemented.
You are assuming that it would be implemented in ways
that you are familiar with. That is a wrong
assumption.
Linux isn't going to make progress when people try to
figure out how to make something NOT work rather than
to make something work. So if you are going to put
effort into this then why not try to figure out how to
get around the issues you are raising rather than to
attack the idea as unsolvable.
When I originally suggested that the names would be a
"hash" I didn't mean that it is going to be only a
hash. You have successfully argued that just a hash
would have problems. Which means that a real solution
is going to be more complex.
I suggest that it would be easier to figure out how to
make moves of large directory structure fast and
effecient with automatic inheritance of rights.
I know it can be done because Microsoft is doing it
and Novell Netware was doing it 20 years ago. So the
fact that it is done by others disproves your
arguments that it can't be done.
Marc Perkel
Junk Email Filter dot com
http://www.junkemailfilter.com
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play
Sims Stories at Yahoo! Games.
http://sims.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 17, 2007, at 15:01:48, Phillip Susi wrote:
[EMAIL PROTECTED] wrote:
It will become even *more* of a not that common
if the lock will
block moves and ACL changes *across the
filesystem* for
potentially *minutes* at a time.
It will not take anywhere NEAR minutes at a time
to update the in
memory dentries, more like 50ms.
One last comment:
50ms to update in-memory dentries would be FRIGGING
TERRIBLE!!!
Using Perl, an interpreted language, the following
script takes 3.39s
to run on one of my lower-end systems:
for (0 .. 1) {
mkdir a-$_;
mkdir b-$_;
rename a-$_, b-$_;
}
It's not even deleting things afterwards so it's
populating a
directory with ten thousand entries. We can easily
calculate
10,000/3.39 = 2,949 entries per second, or 0.339
milliseconds per entry.
When I change it to rmdir things instead, the
runtime goes down to
2.89s == 3460 entries/sec == 0.289 milliseconds per
entry.
If such a scheme even increases the overhead of a
directory rename by
a hundredth of a millisecond on that box it would
easily be a 2-3%
performance hit. Given that people tend to kill for
1% performance
boosts, that's not likely to be a good idea.
Cheers,
Kyle Moffett
What I suggested was a concept of a new way to look at
a file system. What you are arguing here is why it
wouldn't work based on your theories as to how such a
file system would be implemented. In attacking how
slow you think it might be you are making assumptions
that wouldn't apply to how this would be implemented.
You are assuming that it would be implemented in ways
that you are familiar with. That is a wrong
assumption.
Linux isn't going to make progress when people try to
figure out how to make something NOT work rather than
to make something work. So if you are going to put
effort into this then why not try to figure out how to
get around the issues you are raising rather than to
attack the idea as unsolvable.
When I originally suggested that the names would be a
hash I didn't mean that it is going to be only a
hash. You have successfully argued that just a hash
would have problems. Which means that a real solution
is going to be more complex.
I suggest that it would be easier to figure out how to
make moves of large directory structure fast and
effecient with automatic inheritance of rights.
I know it can be done because Microsoft is doing it
and Novell Netware was doing it 20 years ago. So the
fact that it is done by others disproves your
arguments that it can't be done.
Marc Perkel
Junk Email Filter dot com
http://www.junkemailfilter.com
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play
Sims Stories at Yahoo! Games.
http://sims.yahoo.com/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
No Al, there isn't any shortage of arrogance here. Let me try to repeat what I'm talking about as simply as I can. First - I'm describing a kind of functionality and suggesting Linux should have it. I know a lot of it can be done because much of what I'm suggesting is already working in Windows and Netware. I'm not the one who's going to code it. I'm just saying that it would be nice if Linux had the functionality of other operating systems - and - take it to the next level - match it and do even better. As to thinking outside the box, what I'm proposing is outside the box relative to Linux. It's not as original as compared to Windows or Netware which is even better. The idea is that Linux is lacking features that other OSs have. What I'm suggesting is that Linux not only match it but to create an even more powerful rights layer that is more powerful than the rest and I'm outlining a concept in the hopes that people would get excited about the concept and want to build on the idea. I'm just telling you what I'd like to see. I'm not going to code it. So I'm only going to talk about what is possible. How it's done will be up to any programmers who might be inspired by the idea. If no one is inspired the Linux will continue to be in last place when it comes to file system features relating to fine grain permissions. In Linux, for example, users are allowed to delete files that they are prohibited from reading or writing. In Netware if a user can't read or write to the file they won't even be able to see that the file exists, let alone delete it. In Netware I can move a directory tree into another tree and the objects that have rights in the other tree will have rights to all the new files without having to run utilities on the command line to recursively change the permission afterwards. The point - Linux isn't going to move forward and catch up unless there is a fundamental change in the thinking behind Linux permissions. There is a cultural lack of innovation here. I discussed this with Andrew Morton and he made some suggestions but there's real hostility towards new concepts here. Something I don't understand. At some point Linux needs to grow beyond just being an evolved Unix clone and that's not going to happen if you don't think differently. I still believe that the VI editor causes brain damage. :) Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
The vi editor causes brain damage
Let me give you and example of the difference between Linux open source world brain damaged thinking and what it's like out here in the real world. Go to a directory with 10k files and type: rm * What do you get? /bin/rm: Argument list too long If you map a network drive in DOS and type: del * It works. That's the problem with the type of thinking in the open source world. Why can DOS delete an infinite number of files and rm can't? Because rm was written using the vi editor and it causes brain damage and that's why after 20 years rm hasn't caught up with del. Before everyone gets pissed off and freaks out why don't you ponder the question why rm won't delete all the files in the directory. If you can't grasp that then you're brain damaged. Think big people. Say NO to vi! Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
Several people have asked about how to mass move a tree under my idea for a new kind of file system. I have an idea. Suppose you have the file name as follies. /one/two/three/four/file1 Except the are a million files in /four/ named file1 to file100. We want to move thes files to /seven/six/five. How do you do that fast? Here's an idea. Suppose you have a hash not only of files but of the directory sections. Every new section is added and givem a number. For simplicity the table might look like this: one 1 two 2 three 3 four 4 five 5 six 6 seven 7 So what the path is reduced to is /1/2/3/4 which point to those names. So if you want to move it then you change the names in the database. seven 1 six 2 five 3 And then everything that's stored as /1/2/3/4 is still the same but the sections resolve to different names. I'm sure there are errors in my logic but I'm trying to show that if you are persistent in trying to come up with ideas on how to do something you will eventually make it work. But if you are looking for ways to make it not work then you probably won't solve it. So the correct response to this message isn't to prove that my method won't work, but to come up with a method that will work. You have to look for a solution rather than attack other people's solutions. That's what thinking outside the box means. Impossible = Challenge Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
Several people have asked about how to mass move a tree under my idea for a new kind of file system. I have an idea. Suppose you have the file name as follies. /one/two/three/four/file1 Except the are a million files in /four/ named file1 to file100. We want to move thes files to /seven/six/five. How do you do that fast? Here's an idea. Suppose you have a hash not only of files but of the directory sections. Every new section is added and givem a number. For simplicity the table might look like this: one 1 two 2 three 3 four 4 five 5 six 6 seven 7 So what the path is reduced to is /1/2/3/4 which point to those names. So if you want to move it then you change the names in the database. seven 1 six 2 five 3 And then everything that's stored as /1/2/3/4 is still the same but the sections resolve to different names. I'm sure there are errors in my logic but I'm trying to show that if you are persistent in trying to come up with ideas on how to do something you will eventually make it work. But if you are looking for ways to make it not work then you probably won't solve it. So the correct response to this message isn't to prove that my method won't work, but to come up with a method that will work. You have to look for a solution rather than attack other people's solutions. That's what thinking outside the box means. Impossible = Challenge Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- [EMAIL PROTECTED] wrote: > On Wed, 15 Aug 2007 13:50:17 PDT, Marc Perkel said: > > I don't see it as being any worse that what we > have > > now. To open a file you have to start at the > bottom > > and open each directory and evaluate the > permissions > > on the way to the file. In my system you have to > look > > up the permission of the string at each "/" > separator. > > Seems to me that every system would have these > same > > steps. > > No - you need to look at the *whole* string - that's > the > whole *point* of your system, remember? > > Just a few msgs back, you gave a nice example of > having a file with \ in the name rather than / > because > it came from a Windows user. So you *do* need to > check *every* > pattern against the filename, because it *could* > match. > In a system with several hundred thousand or more > patterns, > that could be painful. > > Also, you need to figure out how to deal with all > the various > silly corner cases that people will end up trying to > do. > > Consider the rules: > > peter '*a*' can create > peter '*b*' cannot create > > Peter tries to create 'foo-ab-bar' - is he allowed > to or not? > First - I'm proposing a concept, not writing the implementation of the concept. You are asking what happens when someone write conflicting rules. That depends on how you implement it. Conflicting rules can cause unpredictable results. It may be as simple as first rule wins. Or it may require all the rules to be true. In the above example I would say it is not allowed because it matches a denial condition. The point is that one can choose any rule system they want and the rules applies to the names of the files and the permissions of the users. > For an exersize, either write a program or do by > hand: > > Create a list of patterns that correctly express the > ownership > and permissions of *every* file on your current > Linux box. > > Then repeat on a large box with multiple users and a > few Oracle > databases or webservers. > > Then write a small tool, that given that list, a > username, > a filename, and the operation (read, write, open, > unlink, etc), > says "Yes or No". > > Then run 'strace /bin/ls' in a large directory, take > all the > filenames listed in the strace output, and see if > your tool can > answer "yes or no" fast enough to make 'ls' > feasible. > > Come back when you get that part done, and we'll > discuss how it > would have to work in the kernel. All you would have to do is create a set of rules that emulates the current rules and you would have the same results. > Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > Al Viro added to the CC, since he's one of the > experts on this stuff > and will probably whack me with a LART for > explaining it all wrong, > or something. :-D > Thanks - I appreciate that. Just to catch everyone up on what this thread is about, I'm proposing a new way of looking at file systems where files no longer have permission, owners, or groups, or file attributes. The idea is that people, groups, managers, applications, and other objects have permissions to names that are pointers to files. > On Aug 15, 2007, at 16:38:36, Phillip Susi wrote: > > Kyle Moffett wrote: > >> We've *always* had to do this; that's what "chmod > -R" or "setfacl - > >> R" are for :-D. The major problem is that the > locking and lookup > >> overhead gets really significant if you have to > look at the entire > >> directory tree in order to determine the > permissions for one > >> single object. I definitely agree that we need > better GUIs for > >> managing file permissions, but I don't see how > you could modify > >> the kernel in this case to do what you want. > > > > I am well aware of that, I'm simply saying that > sucks. Doing a > > recursive chmod or setfacl on a large directory > tree is slow as all > > hell. > > Doing it in the kernel won't make it any faster. > > > > As for hard links, your access would depend on > which name you use > > to access the file. The file itself may still > have an acl that > > grants or denies access to people no matter what > name they use, but > > if it allows inheritance, then which name you > access it by will > > modify the effective acl that it gets. > > You can't safely preserve POSIX semantics that way. > For example, > even without *ANY* ability to read /etc/shadow, I > can easily "ln /etc/ > shadow /tmp/shadow", assuming they are on the same > filesystem. If > the /etc/shadow permissions depend on inherited ACLs > to enforce > access then that one little command just made your > shadow file world- > readable/writeable. Oops. > > Think about it this way: > Permissions depend on *what* something is, not > *where* it is. Under > Linux you can leave the digital equivalent of a > $10,000 piece of > jewelry lying around in /var/www and not have to > worry about it being > compromised as long as you set your permissions > properly (not that I > recommend it). Moving the piece of jewelry around > your house does > not change what it *is* (and by extension does not > change the > protection required on it), any more than "ln > /etc/shadow /tmp/ > shadow" (or "mv") changes what *it* is. If your > /house is really > extraordinarily secure then you could leave the > jewelry lying around > as /house/gems.bin with permissions 0777, but if > somebody had a back- > door to /house (an open fd, a careless typo, etc) > then you'd have the > same issues. My proposal is the same somewhat. If one put restricting on a specific name to deny access to users then that denial follows that filename even if it is copied or moved. However if a file has no specific restrictions and is in a restricted directory then the file inherits the restrictions and permissions of the new directory based on where it is. If you don't want your jewlery laying around then don't put a copy of it in a folder where users have access to it. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Phillip Susi <[EMAIL PROTECTED]> wrote: > Marc Perkel wrote: > > > > Kyle - you are still missing the point. chmod goes > > away. File permissions goes away. Directories as > you > > know them goes away. > > You are missing the point Marc... open()ing a file > will have to perform > a number of these pattern matches to decide if it is > allowed or not... > this would be a HUGE overhead. > > I don't see it as being any worse that what we have now. To open a file you have to start at the bottom and open each directory and evaluate the permissions on the way to the file. In my system you have to look up the permission of the string at each "/" separator. Seems to me that every system would have these same steps. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > On Aug 15, 2007, at 15:26:07, Lennart Sorensen > wrote: > > On Wed, Aug 15, 2007 at 10:59:12AM -0700, Marc > Perkel wrote: > >> When one thinks outside the box one has to think > about evolving > >> beyond what you are used to. When I moved > >> beyond DOS I have to give up the idea of 8.3 file > names. The idea > >> here is to come up with a model that can emulate > the existing > >> system for backwards compatibility. > > > > But moving beyond 8.3 didn't prevent you from > still using 8.3 names > > if you wanted too. Longer file names are just an > extension of > > shorter ones. > > As another example, take a look at "git", the SCM we > use for the > kernel, as contrasted with the older CVS. You can > import your > complete CVS history into it without data loss, and > then you can even > continue to use it the exact same way you used to > use CVS, with some > slight differences in command-line syntax. Once you > are ready to > move further, though, you can create multiple local > branches to have > your co-workers pull from to test changes. You > discover that merging > branches is much easier in git than in CVS. Your > company starts to > use a more distributed development model, they > implement a policy > telling developers to break up their changes into > smaller pieces and > write better change-logs. Somebody suddenly > discovers the ability to > "sign" a particular release version with a private > key, and you start > doing that as part of your release management to > ensure that the > codebase marked with a client tag is the exact same > one you actually > shipped to that client. > > On a fundamental level, GIT is a completely > different paradigm from > CVS. Its internal operations are entirely > differently organized, it > uses different algorithms and different storage > formats. The end > result of that is that it's literally orders of > magnitude faster on > large codebases. But to the USER it can be used > exactly the same; > you could even write a little CVS-to-GIT wrapper > which imported your > CVS into a git repo and then let you operate on it > using "gcvs" > commands the same way you would have operated on > real CVS repositories. > > Just some food for thought > > Cheers, > Kyle Moffett > Yes - that's a good example. Git is far more powerful and a different paradigm for CVS. Someone had to think outside the box and come up with a new way of looking at things. I'm trying to do something like that with this idea. To me it make more sense to get rid of file permissions and look at people permissions. It reminds me of a story a friend of mine told about her 4 year old son. The story was that they were driving down the road when they saw a wheel come off a truck. The son said, "look mommy, that wheel lost it's truck." To me files are like the wheel. Rather than having the file know all it's owners it makes more sense for the owners to know it's files. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail=summer+activities+for+kids=bz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Craig Ruff <[EMAIL PROTECTED]> wrote: > On Wed, Aug 15, 2007 at 10:30:19AM -0700, Marc > Perkel wrote: > > --- Kyle Moffett <[EMAIL PROTECTED]> wrote: > > > Except they do, and without directories the > > > performance of your average filesystem is going > to suck. > > > > Actually you would get a speed improvement. You > hash > > the full name and get the file number. You don't > have > > to break up the name into sections except for > > evaluating name permissions. > > > > The important concept here is that files and name > > aren't stored by levels of directories. The name > > points to the file number. Directory levels are > > emulated based on name separation characters or > any > > other algorithm that you want to use. > > > > One could create a file system and permission > system > > that gets rid of the concept of directories > entirely > > if one chooses to. > > I would like to add support for Kyle's assertion. > > The model described by Marc is exactly the method > used by the current > version of the NCAR Mass Storage Service (MSS), > which is data archive > of 4+ petabytes contained in 40+ million files. To > the user's point > of view, it looks somewhat like a POSIX file system > with both some > extensions and deficiencies. The MSS was designed > in the mid-1980s, > in an era where the costs of the supercomputers > (Cray-1s at that time) > were paramount. This lead to some MSS design > decisions to minimize the > need for users to rerun jobs on the expensive > supercomputer just because > they messed up their MSS file creation statements. > > Files names are a maximum of 128 bytes, with a > dynamically managed > directory structure indicated by '/' characters in > the name. The file > name is hashed, and the hash table provides the > internal file number (the > address in the Master File Directory (MFD)). Any > parent directories > are created automatically by the system upon file > creation, and are > automatically deleted if empty upon file deletion. > Directories also > have a self pointer, and both files and directories > are chained together > to allow the user to list (or otherwise manipulate) > the contents of > a directory. > > The biggest problem with this model is that to > manipulate the a directory > itself, you have to simulate the operation on all of > the files contained > within it. For example to rename a directory with > 'n' descendants, > you must perform: > > n+1 hash table removals > n+1 hash table insertions (with collision > detection) > n+1 MFD record updates > 1 directory chain removal > 1 directory chain insertion > > This is, needless to say, very painful when n is > large. Since users > must use directory trees to efficiently manage their > data holdings, > efficient directory manipulation is essential. > Contrast this with > the number of operations required for a directory > rename if files > do not record their complete pathname: > > 1 directory chain removal > 1 directory chain insertion > > Fortunately we are currently working to change from > using a model like > Marc describes to one Kyle describes. > I am describing a kind of functionality and not tied to the method that implements that functionality. Perhaps a straight hash of the name isn't the best way to implement it. Just because someone tried to do something like what I'm suggesting years ago and it didn't work doesn't mean that it can't be done. You just have to come up with a better method. Lets take this example. We are moving a million files from one branch if a tree to another. Do we wait for a million renames and hashes to occur? Of course not. So what to we do? We continue to be innovative. One must first adopt the attitude that anything can be done - you just have to be persistent until you figure out how. In this case we could have a name translation layer so if you want to do a move you change the translation layer indicating that a move occurred. Thus access to the new files get translated into the old name and accessed until the files are rehashed. Or - maybe there is some sort of tokenizer database for the names in the directory sections and you can just rename the section. Sort of a tree like database of hashes data within hashes. My point - you start with what you want to do and then you figure out how to make it happen. I can't answer all the details of how to make it happen but when I do something I start with the idea that if this were done right it would work this way and then I figure out how. Marc Perkel Junk Email Filter dot com http://w
Re: Thinking outside the box on file systems
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > On Aug 15, 2007, at 14:05:23, Marc Perkel wrote: > > In this new system setfacl, chmod, chown, and > chgrp all go away > > except inside of an emulation layer. File and > directories no longer > > have permissions. People have permission to naming > patterns. So if > > you put a file into a tree or move a tree then > those who have > > permissions to the tree have access to the files. > > > > It eliminates the step of having to apply > permission after moving > > files into a tree. You don't have to change file > permissions > > because files no longer have permissions. > > And I'm trying to tell you that unless you have some > magic new > algorithm that turns NP-complete problems into > O(log(N)) problems, > your idea won't work. You can't just say "I just do > one little thing > (mv) and the entire rest of the computer > automagically changes to > match", because that would imply a single unscalable > global kernel > lock. "Pattern"-matching is either NP-complete or > high-polynomial- > order, depending on how its implemented, and if you > want to do a > recursive-chmod during a directory move then you're > going to have > race-conditions out the ass. If you have code or > solid math to back > up your postings then please do so, but otherwise > you're just wasting > time and bandwidth. > > Kyle - you are still missing the point. chmod goes away. File permissions goes away. Directories as you know them goes away. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail=summer+activities+for+kids=bz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
Kyle, In this new system setfacl, chmod, chown, and chgrp all go away except inside of an emulation layer. File and directories no longer have permissions. People have permission to naming patterns. So if you put a file into a tree or move a tree then those who have permissions to the tree have access to the files. It eliminates the step of having to apply permission after moving files into a tree. You don't have to change file permissions because files no longer have permissions. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > On Aug 15, 2007, at 13:19:16, Marc Perkel wrote: > > One of the problems with the Unix/Linux world is > that your minds > > are locked into this one model. In order to do it > right it requires > > the mental discipline to break out of that. > > The major thing that you are missing is that this > "one model" has > been very heavily tested over the years. People > understand it, know > how to use it and write software for it, and grok > its limitations. > There's also a vast amount of *existing* code that > you can't just > "deprecate" overnight; the world just doesn't work > that way. The > real way to get there (IE: a new model) from here > (IE: the old model) > is the way all Linux development is done with a lot > of sensible easy- > to-understand changes and refactorings. > > With that said, if you actually want to sit down and > start writing > *code* for your model, go ahead. If it turns out to > be better than > our existing model then I owe you a bottle of your > favorite beverage. > > Cheers, > Kyle Moffett > When one thinks outside the box one has to think about evolving beyond what you are used to. When I moved beyond DOS I have to give up the idea of 8.3 file names. The idea here is to come up with a model that can emulate the existing system for backwards compatibility. The concept behind my model is to create a new layer where you can do ANYTHING with file names and permissions and create models that emulate Linux, DOS, Windows, Mac, or anything else you can dream of. Then you can create a Linux/Windows/Mac template to emulate what you are used to. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Phillip Susi <[EMAIL PROTECTED]> wrote: > Kyle Moffett wrote: > > Going even further in this direction, the > following POSIX ACL on the > > directories will do what you want: > > > > ## Note: file owner and group are kmoffett > > u::rw- > > g::rw- > > u:lsorens:rw- > > u:mtharp:rw- > > u:mperkel:rw- > > g:randomcvsdudes:r- > > default:u::rw- > > default:g::rw- > > default:u:lsorens > > default:u:mtharp:rw- > > default:u:mperkel:rw- > > default:g:randomcvsdudes:r- > > > The problem that I have with this setup is that it > specifies an ACL on > EACH file. Yes, you can set a default on the > directory for newly > created files, but what if I want to add a user to > the access list for > that whole directory? I have to individually update > every acl on every > file in that directory. Also if you move a file > created elsewhere into > that directory, it retains its existing permissions > doesn't it? I would > rather just add a new ace to the directory itself > which specifies that > it applies to the entire tree. Then you only need > to store a single acl > on disk, and only have to update one acl to add a > new user. > > In the model I'm suggesting files and directories no longer have permissions so ACLs go away. Only users, groups, managers, applications, and other objects have permissions. So if you move a file into the tree then everything that has permission to that tree has rights to the file. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Michael Tharp <[EMAIL PROTECTED]> wrote: > Marc Perkel wrote: > > That not a problem - it's a feature. In such a > > situation the person would get a general file > creation > > error. > > Feature or not, it's still vulnerable to probing by > malicious users. If > there are create permissions on the directory, the > invisibility is not > perfect. In a real world situation I would think that users probing for invisible files is more secure that users knowing the names of files that they have no access to. > > > Although it isn't likely people would structure > > files with invisible files in directories that the > > user has create permissions [...] > > ... /tmp ... You're still thinking inside the box. Let's take the tmp directory for example. /tmp wpuld probably g away in favor of persomal /tmp directories. As we all know, /tmp is the source of a lot of vulnerabilities. One might put a name translation mask on the /tmp name in the file name translation system. For example: /tmp -> my /tmp Thus files written to /tmp would become /mperkel/tmp and users wouldn't be able to see other users /tmp files or have any name conflicts. Let me explain about the concept of thinking outside the box. If you run into a problem you figure out a new solution. It's about finding ways to make things work rather than finding ways to make things not work. So - we are not only talking about a name permission system but a file name translation system. Thus a user's view of the file system might not be the same for all users. In fact, let's say that mperkel is a Windows user and is just attacking to Linus as a file system. Because mperkel is in the windows group the file system appears as h:\home\mperkel on a native Linux level and mounts are drive letters. It would use a Windows name translation mask program that would be part of the permission/naming system. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > On Aug 15, 2007, at 13:09:31, Marc Perkel wrote: > > The idea is that people have permissions - not > files. By people I > > mean users, groups, managers, applications > > etc. One might even specify that there are no > permission > > restrictions at all. Part of the process would be > that the kernel > > load what code it will use for the permission > system. It might even > > be a little perl script you write. > > > > Also - you aren't even giving permission to access > files. It's > > permission to access name patterns. One could > apply REGEX masks to > > names to determine permissions. So if you have > permission to the > > name you have permission to the file. > > Please excuse me, I'm going to go stand over in the > corner for a minute. > > *hahahahahaa hahahahahaaa hahaa hoo hee snicker > sniff* > > *wanders back into the conversation* > > Sorry about that, pardon me. > > I suspect you will find it somewhat hard to convince > *anybody* on > this list to put either a regex engine or a Perl > interpreter into the > kernel. I doubt you could even get a simple > shell-style pattern > matcher in. First of all, both of the former chew > up enormous gobs > of stack space *AND* they're NP-complete. You just > can't do such > matching even in polynomial time, let alone > something that scales > appropriately for an OS kernel like, say, O(log(n)). > > Cheers, > Kyle Moffett > Keep in mind that this is about thinking outside the box. Don't let new ideas scare you. I'm not suggesting that the kernel contain perl. I'm saying that you can let the kernel call a perl program in user space to control part of the permission system. There are examples of this in FUSE. What I'm suggesting would be very FUSE friendly. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail=summer+activities+for+kids=bz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: . > > > The important point here is that directories don't > really exist. > > Except they do, and without directories the > performance of your > average filesystem is going to suck. > Actually you would get a speed improvement. You hash the full name and get the file number. You don't have to break up the name into sections except for evaluating name permissions. The important concept here is that files and name aren't stored by levels of directories. The name points to the file number. Directory levels are emulated based on name separation characters or any other algorithm that you want to use. One could create a file system and permission system that gets rid of the concept of directories entirely if one chooses to. That's outside the box big time. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > On Aug 15, 2007, at 12:02:41, Marc Perkel wrote: > > Kyle, thinking further outside the box, files > would no longer have > > owners or permissions. Nor would > > directories. People, groups, managers, and other > objects with have > > permissions. One might tag a file with the object > that created it > > so you could implement "self" rights which might > be use to replace > > the concept of /tmp directories. > > Well, that's actually kind of close to how SELinux > works. > > This is the real fundamental design gotcha: >Our current apps *AND* admins speak "UNIX" and > "POSIX". They > don't speak "MarcPerkelOS" (or even "SELinux"). As > long as there is > not a reasonably-close-to-1-to-1 mapping between > UNIX semantics and > your "outside the box" semantics, the latter can't > really be used. > It would just involve rewriting too much code *AND* > retraining too > many admins from scratch to make it work. Hell, > even Windows and Mac > have moved towards a UNIX-like permissions system, > precisely because > it's a simple model which is relatively easy to > teach people how to > use. ACLs are just a slight modification of that > model to allow two > things: >(A) Additional user/group permissions >(B) Default permissions for new child > files/dirs/etc > > People are having a huge problem with SELinux > permissions as is, and > portions of that are a fairly standard model that's > been worked over > in various OSes for many years. I seriously doubt > that anything that > far "outside the box" is going to be feasible, at > least in the near > term. > > Good new filesystem developments are likely to be > ones which preserve > the same outer model, yet allow for > deeper/more-powerful control for > those users/admins who need it. > > Cheers, > Kyle Moffett > > Kyle, What I'm suggesting is scrapping all existing concepts and replacing them with something entirely new. Posix, Unix, SELinux go away except for an emulation layer for backwards compatibility. What I'm suggesting is to start over and do it right. If this new idea is implemented then one could implement POSIX as one of many permission modules that one could load. One could also load a WINDOWS permission model that could be used with SAMBA. This would be a new more powerful underlying layer that can be used to emulate anything you want. And it would be great for people using FUSE who could make file systems look any way they want. One of the problems with the Unix/Linux world is that your minds are locked into this one model. In order to do it right it requires the mental discipline to break out of that. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- [EMAIL PROTECTED] wrote: > On Wed, 15 Aug 2007 09:02:41 PDT, Marc Perkel said: > > > Kyle, thinking further outside the box, files > would no > > longer have owners or permissions. Nor would > > directories. People, groups, managers, and other > > objects with have permissions. > > You gotta think *way* out of the box to come up with > a system where a "file" > isn't an object that can have some sort of ACL or > permissions on it. > Yep - way outside the box - and thus the title of the thread. The idea is that people have permissions - not files. By people I mean users, groups, managers, applications etc. One might even specify that there are no permission restrictions at all. Part of the process would be that the kernel load what code it will use for the permission system. It might even be a little perl script you write. Also - you aren't even giving permission to access files. It's permission to access name patterns. One could apply REGEX masks to names to determine permissions. So if you have permission to the name you have permission to the file. Hard links would be multiple names pointing to the same file. Simlinks would be name aliases. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- alan <[EMAIL PROTECTED]> wrote: > On Tue, 14 Aug 2007, Marc Perkel wrote: > > > For example. If you list a directory you only see > the > > files that you have some rights to and files where > you > > have no rights are invisible to you. If a file is > read > > only to you then you can't delete it either. > Having > > write access to a directory really means that you > have > > file create rights. You can also delete files that > you > > have write access to. You would also allocate > > permissions to manage file rights like being able > to > > set the rights of inferior users. > > Imagine the fun you will have trying to write a file > name and being told > you cannot write it for some unknown reason. > Unbeknownst to you, there is > a file there, but it is not owned by you, thus > invisible. > > Making a file system more user oriented would avoid > little gotchas like > this. The reason it is "programmer oriented" is > that those are the people > who have worked out why it works and why certain > things are bad ideas. > That not a problem - it's a feature. In such a situation the person would get a general file creation error. Although it isn't likely people would structure files with invisible files in directories that the user has create permissions it is logical that if I put a file in a place where the user has no rights I want it to stay there. Currently the user can delete files where they have no rights. I might also want to restrict the kind of a user can createor give permission to create only certian file names. /etc/vz/conf/*.conf - create - readonly - self-rw /etc/vz/conf - deny This would allow the user to read all *.conf files, create new *.conf files, and full permissions to read/write/delete files that the user created but not files that others created. If listing a directory then only the *.conf files would appear even if other files are in the directory. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Michael Tharp <[EMAIL PROTECTED]> wrote: > Kyle Moffett wrote: > > Basically any newly-created item in such a > directory will get the > > permissions described by the "default:" entries in > the ACL, and > > subdirectories will get a copy of said "default:" > entries. > > This would work well, although I would give write > permissions to a group > so the entire dir wouldn't need to be re-ACLed when > a user is added. I > may give this a shot; I've been avoiding ACLs > because they have always > sounded incomplete/not useful, but the inheritance > aspect sounds rather > nice. Michael, my idea in this model is that there will be no permissions stored in files. So you would not have to re-ACL anything. What I'm thinking is there would be a new permission system that is completely different. It might be something like this. I am loged in as mperkel. I get all the rights of mperkel and all other objects like groups or management lists that I am a member of. Once the system has a full list of my rights it starts to compare the file name I'm trying to access to the rights I have by testing each section of the name. So if the file is /home/mperkel/files/myfile then the test would be: /home/mperkel/files/myfile - nothing /home/mperkel/files - nothing /home/mperkel - match - mperkel granted tree permission Rights tests would be based on trees so if you hit a tree permission they you can access anything in the tree unless you have hit a deny in the branches. All of this is based on the text strings in the file name with the "/" separator for the tests. The correct way of thinking of this is applying permissions to name strings. Directories will become artificial constructs. For example, one might grant permissions for files: /etc/*.conf - read only /etc - deny In this example the user would be able to read any file in the /etc directory that ended in *.conf but no other files. If the object listed the /etc directory it would only show the *.conf files and no other file would appear to exist. The important point here is that directories don't really exist. Imagine that every file has an internal number that is linked to the blocks that contain that file. Then there are file names that link to that number directly. Then there is a permission system that compares the name you are requesting to a permission algorithm that determines what you are allowed to do to the name that you are requesting. For example, you want to list all file names /etc/*. Each name is fetched and your permissions are compared to each item and you get a list of names that you have some permission to access. If you have no permission to a name that exists then you don't see the name. Thus, suppose you have this permission /etc/pass* - deny Then you will not only be denied access to the /etc/passwd file, you wouldn't even be able to tell if it exists. The root user for compatibility would have permissions to everything. It would be like a super manager. Managers would be objects that have limited ability to alter the permissions for other users or objects that they manage. I'm also thinking there would be a "kernel" user which would be a level above the root user where the kernel would have access to files that even the root user can't see (unless debug modes are set) so that some files can be system only or readable by root but writable by kernel. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > > ## Note: file owner and group are kmoffett > u::rw- > g::rw- > u:lsorens:rw- > u:mtharp:rw- > u:mperkel:rw- > g:randomcvsdudes:r- > default:u::rw- > default:g::rw- > default:u:lsorens > default:u:mtharp:rw- > default:u:mperkel:rw- > default:g:randomcvsdudes:r- Kyle, thinking further outside the box, files would no longer have owners or permissions. Nor would directories. People, groups, managers, and other objects with have permissions. One might tag a file with the object that created it so you could implement "self" rights which might be use to replace the concept of /tmp directories. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail=summer+activities+for+kids=bz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett [EMAIL PROTECTED] wrote: ## Note: file owner and group are kmoffett u::rw- g::rw- u:lsorens:rw- u:mtharp:rw- u:mperkel:rw- g:randomcvsdudes:r- default:u::rw- default:g::rw- default:u:lsorens default:u:mtharp:rw- default:u:mperkel:rw- default:g:randomcvsdudes:r- Kyle, thinking further outside the box, files would no longer have owners or permissions. Nor would directories. People, groups, managers, and other objects with have permissions. One might tag a file with the object that created it so you could implement self rights which might be use to replace the concept of /tmp directories. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mailp=summer+activities+for+kidscs=bz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Michael Tharp [EMAIL PROTECTED] wrote: Kyle Moffett wrote: Basically any newly-created item in such a directory will get the permissions described by the default: entries in the ACL, and subdirectories will get a copy of said default: entries. This would work well, although I would give write permissions to a group so the entire dir wouldn't need to be re-ACLed when a user is added. I may give this a shot; I've been avoiding ACLs because they have always sounded incomplete/not useful, but the inheritance aspect sounds rather nice. Michael, my idea in this model is that there will be no permissions stored in files. So you would not have to re-ACL anything. What I'm thinking is there would be a new permission system that is completely different. It might be something like this. I am loged in as mperkel. I get all the rights of mperkel and all other objects like groups or management lists that I am a member of. Once the system has a full list of my rights it starts to compare the file name I'm trying to access to the rights I have by testing each section of the name. So if the file is /home/mperkel/files/myfile then the test would be: /home/mperkel/files/myfile - nothing /home/mperkel/files - nothing /home/mperkel - match - mperkel granted tree permission Rights tests would be based on trees so if you hit a tree permission they you can access anything in the tree unless you have hit a deny in the branches. All of this is based on the text strings in the file name with the / separator for the tests. The correct way of thinking of this is applying permissions to name strings. Directories will become artificial constructs. For example, one might grant permissions for files: /etc/*.conf - read only /etc - deny In this example the user would be able to read any file in the /etc directory that ended in *.conf but no other files. If the object listed the /etc directory it would only show the *.conf files and no other file would appear to exist. The important point here is that directories don't really exist. Imagine that every file has an internal number that is linked to the blocks that contain that file. Then there are file names that link to that number directly. Then there is a permission system that compares the name you are requesting to a permission algorithm that determines what you are allowed to do to the name that you are requesting. For example, you want to list all file names /etc/*. Each name is fetched and your permissions are compared to each item and you get a list of names that you have some permission to access. If you have no permission to a name that exists then you don't see the name. Thus, suppose you have this permission /etc/pass* - deny Then you will not only be denied access to the /etc/passwd file, you wouldn't even be able to tell if it exists. The root user for compatibility would have permissions to everything. It would be like a super manager. Managers would be objects that have limited ability to alter the permissions for other users or objects that they manage. I'm also thinking there would be a kernel user which would be a level above the root user where the kernel would have access to files that even the root user can't see (unless debug modes are set) so that some files can be system only or readable by root but writable by kernel. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- alan [EMAIL PROTECTED] wrote: On Tue, 14 Aug 2007, Marc Perkel wrote: For example. If you list a directory you only see the files that you have some rights to and files where you have no rights are invisible to you. If a file is read only to you then you can't delete it either. Having write access to a directory really means that you have file create rights. You can also delete files that you have write access to. You would also allocate permissions to manage file rights like being able to set the rights of inferior users. Imagine the fun you will have trying to write a file name and being told you cannot write it for some unknown reason. Unbeknownst to you, there is a file there, but it is not owned by you, thus invisible. Making a file system more user oriented would avoid little gotchas like this. The reason it is programmer oriented is that those are the people who have worked out why it works and why certain things are bad ideas. That not a problem - it's a feature. In such a situation the person would get a general file creation error. Although it isn't likely people would structure files with invisible files in directories that the user has create permissions it is logical that if I put a file in a place where the user has no rights I want it to stay there. Currently the user can delete files where they have no rights. I might also want to restrict the kind of a user can createor give permission to create only certian file names. /etc/vz/conf/*.conf - create - readonly - self-rw /etc/vz/conf - deny This would allow the user to read all *.conf files, create new *.conf files, and full permissions to read/write/delete files that the user created but not files that others created. If listing a directory then only the *.conf files would appear even if other files are in the directory. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- [EMAIL PROTECTED] wrote: On Wed, 15 Aug 2007 09:02:41 PDT, Marc Perkel said: Kyle, thinking further outside the box, files would no longer have owners or permissions. Nor would directories. People, groups, managers, and other objects with have permissions. You gotta think *way* out of the box to come up with a system where a file isn't an object that can have some sort of ACL or permissions on it. Yep - way outside the box - and thus the title of the thread. The idea is that people have permissions - not files. By people I mean users, groups, managers, applications etc. One might even specify that there are no permission restrictions at all. Part of the process would be that the kernel load what code it will use for the permission system. It might even be a little perl script you write. Also - you aren't even giving permission to access files. It's permission to access name patterns. One could apply REGEX masks to names to determine permissions. So if you have permission to the name you have permission to the file. Hard links would be multiple names pointing to the same file. Simlinks would be name aliases. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett [EMAIL PROTECTED] wrote: On Aug 15, 2007, at 12:02:41, Marc Perkel wrote: Kyle, thinking further outside the box, files would no longer have owners or permissions. Nor would directories. People, groups, managers, and other objects with have permissions. One might tag a file with the object that created it so you could implement self rights which might be use to replace the concept of /tmp directories. Well, that's actually kind of close to how SELinux works. This is the real fundamental design gotcha: Our current apps *AND* admins speak UNIX and POSIX. They don't speak MarcPerkelOS (or even SELinux). As long as there is not a reasonably-close-to-1-to-1 mapping between UNIX semantics and your outside the box semantics, the latter can't really be used. It would just involve rewriting too much code *AND* retraining too many admins from scratch to make it work. Hell, even Windows and Mac have moved towards a UNIX-like permissions system, precisely because it's a simple model which is relatively easy to teach people how to use. ACLs are just a slight modification of that model to allow two things: (A) Additional user/group permissions (B) Default permissions for new child files/dirs/etc People are having a huge problem with SELinux permissions as is, and portions of that are a fairly standard model that's been worked over in various OSes for many years. I seriously doubt that anything that far outside the box is going to be feasible, at least in the near term. Good new filesystem developments are likely to be ones which preserve the same outer model, yet allow for deeper/more-powerful control for those users/admins who need it. Cheers, Kyle Moffett Kyle, What I'm suggesting is scrapping all existing concepts and replacing them with something entirely new. Posix, Unix, SELinux go away except for an emulation layer for backwards compatibility. What I'm suggesting is to start over and do it right. If this new idea is implemented then one could implement POSIX as one of many permission modules that one could load. One could also load a WINDOWS permission model that could be used with SAMBA. This would be a new more powerful underlying layer that can be used to emulate anything you want. And it would be great for people using FUSE who could make file systems look any way they want. One of the problems with the Unix/Linux world is that your minds are locked into this one model. In order to do it right it requires the mental discipline to break out of that. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. http://farechase.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Phillip Susi [EMAIL PROTECTED] wrote: Kyle Moffett wrote: Going even further in this direction, the following POSIX ACL on the directories will do what you want: ## Note: file owner and group are kmoffett u::rw- g::rw- u:lsorens:rw- u:mtharp:rw- u:mperkel:rw- g:randomcvsdudes:r- default:u::rw- default:g::rw- default:u:lsorens default:u:mtharp:rw- default:u:mperkel:rw- default:g:randomcvsdudes:r- The problem that I have with this setup is that it specifies an ACL on EACH file. Yes, you can set a default on the directory for newly created files, but what if I want to add a user to the access list for that whole directory? I have to individually update every acl on every file in that directory. Also if you move a file created elsewhere into that directory, it retains its existing permissions doesn't it? I would rather just add a new ace to the directory itself which specifies that it applies to the entire tree. Then you only need to store a single acl on disk, and only have to update one acl to add a new user. In the model I'm suggesting files and directories no longer have permissions so ACLs go away. Only users, groups, managers, applications, and other objects have permissions. So if you move a file into the tree then everything that has permission to that tree has rights to the file. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett [EMAIL PROTECTED] wrote: . The important point here is that directories don't really exist. Except they do, and without directories the performance of your average filesystem is going to suck. Actually you would get a speed improvement. You hash the full name and get the file number. You don't have to break up the name into sections except for evaluating name permissions. The important concept here is that files and name aren't stored by levels of directories. The name points to the file number. Directory levels are emulated based on name separation characters or any other algorithm that you want to use. One could create a file system and permission system that gets rid of the concept of directories entirely if one chooses to. That's outside the box big time. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett [EMAIL PROTECTED] wrote: On Aug 15, 2007, at 13:09:31, Marc Perkel wrote: The idea is that people have permissions - not files. By people I mean users, groups, managers, applications etc. One might even specify that there are no permission restrictions at all. Part of the process would be that the kernel load what code it will use for the permission system. It might even be a little perl script you write. Also - you aren't even giving permission to access files. It's permission to access name patterns. One could apply REGEX masks to names to determine permissions. So if you have permission to the name you have permission to the file. Please excuse me, I'm going to go stand over in the corner for a minute. *hahahahahaa hahahahahaaa hahaa hoo hee snicker sniff* *wanders back into the conversation* Sorry about that, pardon me. I suspect you will find it somewhat hard to convince *anybody* on this list to put either a regex engine or a Perl interpreter into the kernel. I doubt you could even get a simple shell-style pattern matcher in. First of all, both of the former chew up enormous gobs of stack space *AND* they're NP-complete. You just can't do such matching even in polynomial time, let alone something that scales appropriately for an OS kernel like, say, O(log(n)). Cheers, Kyle Moffett Keep in mind that this is about thinking outside the box. Don't let new ideas scare you. I'm not suggesting that the kernel contain perl. I'm saying that you can let the kernel call a perl program in user space to control part of the permission system. There are examples of this in FUSE. What I'm suggesting would be very FUSE friendly. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mailp=summer+activities+for+kidscs=bz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Michael Tharp [EMAIL PROTECTED] wrote: Marc Perkel wrote: That not a problem - it's a feature. In such a situation the person would get a general file creation error. Feature or not, it's still vulnerable to probing by malicious users. If there are create permissions on the directory, the invisibility is not perfect. In a real world situation I would think that users probing for invisible files is more secure that users knowing the names of files that they have no access to. Although it isn't likely people would structure files with invisible files in directories that the user has create permissions [...] ... /tmp ... You're still thinking inside the box. Let's take the tmp directory for example. /tmp wpuld probably g away in favor of persomal /tmp directories. As we all know, /tmp is the source of a lot of vulnerabilities. One might put a name translation mask on the /tmp name in the file name translation system. For example: /tmp - my /tmp Thus files written to /tmp would become /mperkel/tmp and users wouldn't be able to see other users /tmp files or have any name conflicts. Let me explain about the concept of thinking outside the box. If you run into a problem you figure out a new solution. It's about finding ways to make things work rather than finding ways to make things not work. So - we are not only talking about a name permission system but a file name translation system. Thus a user's view of the file system might not be the same for all users. In fact, let's say that mperkel is a Windows user and is just attacking to Linus as a file system. Because mperkel is in the windows group the file system appears as h:\home\mperkel on a native Linux level and mounts are drive letters. It would use a Windows name translation mask program that would be part of the permission/naming system. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
Kyle, In this new system setfacl, chmod, chown, and chgrp all go away except inside of an emulation layer. File and directories no longer have permissions. People have permission to naming patterns. So if you put a file into a tree or move a tree then those who have permissions to the tree have access to the files. It eliminates the step of having to apply permission after moving files into a tree. You don't have to change file permissions because files no longer have permissions. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett [EMAIL PROTECTED] wrote: On Aug 15, 2007, at 13:19:16, Marc Perkel wrote: One of the problems with the Unix/Linux world is that your minds are locked into this one model. In order to do it right it requires the mental discipline to break out of that. The major thing that you are missing is that this one model has been very heavily tested over the years. People understand it, know how to use it and write software for it, and grok its limitations. There's also a vast amount of *existing* code that you can't just deprecate overnight; the world just doesn't work that way. The real way to get there (IE: a new model) from here (IE: the old model) is the way all Linux development is done with a lot of sensible easy- to-understand changes and refactorings. With that said, if you actually want to sit down and start writing *code* for your model, go ahead. If it turns out to be better than our existing model then I owe you a bottle of your favorite beverage. Cheers, Kyle Moffett When one thinks outside the box one has to think about evolving beyond what you are used to. When I moved beyond DOS I have to give up the idea of 8.3 file names. The idea here is to come up with a model that can emulate the existing system for backwards compatibility. The concept behind my model is to create a new layer where you can do ANYTHING with file names and permissions and create models that emulate Linux, DOS, Windows, Mac, or anything else you can dream of. Then you can create a Linux/Windows/Mac template to emulate what you are used to. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett [EMAIL PROTECTED] wrote: On Aug 15, 2007, at 14:05:23, Marc Perkel wrote: In this new system setfacl, chmod, chown, and chgrp all go away except inside of an emulation layer. File and directories no longer have permissions. People have permission to naming patterns. So if you put a file into a tree or move a tree then those who have permissions to the tree have access to the files. It eliminates the step of having to apply permission after moving files into a tree. You don't have to change file permissions because files no longer have permissions. And I'm trying to tell you that unless you have some magic new algorithm that turns NP-complete problems into O(log(N)) problems, your idea won't work. You can't just say I just do one little thing (mv) and the entire rest of the computer automagically changes to match, because that would imply a single unscalable global kernel lock. Pattern-matching is either NP-complete or high-polynomial- order, depending on how its implemented, and if you want to do a recursive-chmod during a directory move then you're going to have race-conditions out the ass. If you have code or solid math to back up your postings then please do so, but otherwise you're just wasting time and bandwidth. Kyle - you are still missing the point. chmod goes away. File permissions goes away. Directories as you know them goes away. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mailp=summer+activities+for+kidscs=bz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Craig Ruff [EMAIL PROTECTED] wrote: On Wed, Aug 15, 2007 at 10:30:19AM -0700, Marc Perkel wrote: --- Kyle Moffett [EMAIL PROTECTED] wrote: Except they do, and without directories the performance of your average filesystem is going to suck. Actually you would get a speed improvement. You hash the full name and get the file number. You don't have to break up the name into sections except for evaluating name permissions. The important concept here is that files and name aren't stored by levels of directories. The name points to the file number. Directory levels are emulated based on name separation characters or any other algorithm that you want to use. One could create a file system and permission system that gets rid of the concept of directories entirely if one chooses to. I would like to add support for Kyle's assertion. The model described by Marc is exactly the method used by the current version of the NCAR Mass Storage Service (MSS), which is data archive of 4+ petabytes contained in 40+ million files. To the user's point of view, it looks somewhat like a POSIX file system with both some extensions and deficiencies. The MSS was designed in the mid-1980s, in an era where the costs of the supercomputers (Cray-1s at that time) were paramount. This lead to some MSS design decisions to minimize the need for users to rerun jobs on the expensive supercomputer just because they messed up their MSS file creation statements. Files names are a maximum of 128 bytes, with a dynamically managed directory structure indicated by '/' characters in the name. The file name is hashed, and the hash table provides the internal file number (the address in the Master File Directory (MFD)). Any parent directories are created automatically by the system upon file creation, and are automatically deleted if empty upon file deletion. Directories also have a self pointer, and both files and directories are chained together to allow the user to list (or otherwise manipulate) the contents of a directory. The biggest problem with this model is that to manipulate the a directory itself, you have to simulate the operation on all of the files contained within it. For example to rename a directory with 'n' descendants, you must perform: n+1 hash table removals n+1 hash table insertions (with collision detection) n+1 MFD record updates 1 directory chain removal 1 directory chain insertion This is, needless to say, very painful when n is large. Since users must use directory trees to efficiently manage their data holdings, efficient directory manipulation is essential. Contrast this with the number of operations required for a directory rename if files do not record their complete pathname: 1 directory chain removal 1 directory chain insertion Fortunately we are currently working to change from using a model like Marc describes to one Kyle describes. I am describing a kind of functionality and not tied to the method that implements that functionality. Perhaps a straight hash of the name isn't the best way to implement it. Just because someone tried to do something like what I'm suggesting years ago and it didn't work doesn't mean that it can't be done. You just have to come up with a better method. Lets take this example. We are moving a million files from one branch if a tree to another. Do we wait for a million renames and hashes to occur? Of course not. So what to we do? We continue to be innovative. One must first adopt the attitude that anything can be done - you just have to be persistent until you figure out how. In this case we could have a name translation layer so if you want to do a move you change the translation layer indicating that a move occurred. Thus access to the new files get translated into the old name and accessed until the files are rehashed. Or - maybe there is some sort of tokenizer database for the names in the directory sections and you can just rename the section. Sort of a tree like database of hashes data within hashes. My point - you start with what you want to do and then you figure out how to make it happen. I can't answer all the details of how to make it happen but when I do something I start with the idea that if this were done right it would work this way and then I figure out how. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos more. http://mobile.yahoo.com/go?refer=1GNXIC - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett [EMAIL PROTECTED] wrote: On Aug 15, 2007, at 15:26:07, Lennart Sorensen wrote: On Wed, Aug 15, 2007 at 10:59:12AM -0700, Marc Perkel wrote: When one thinks outside the box one has to think about evolving beyond what you are used to. When I moved beyond DOS I have to give up the idea of 8.3 file names. The idea here is to come up with a model that can emulate the existing system for backwards compatibility. But moving beyond 8.3 didn't prevent you from still using 8.3 names if you wanted too. Longer file names are just an extension of shorter ones. As another example, take a look at git, the SCM we use for the kernel, as contrasted with the older CVS. You can import your complete CVS history into it without data loss, and then you can even continue to use it the exact same way you used to use CVS, with some slight differences in command-line syntax. Once you are ready to move further, though, you can create multiple local branches to have your co-workers pull from to test changes. You discover that merging branches is much easier in git than in CVS. Your company starts to use a more distributed development model, they implement a policy telling developers to break up their changes into smaller pieces and write better change-logs. Somebody suddenly discovers the ability to sign a particular release version with a private key, and you start doing that as part of your release management to ensure that the codebase marked with a client tag is the exact same one you actually shipped to that client. On a fundamental level, GIT is a completely different paradigm from CVS. Its internal operations are entirely differently organized, it uses different algorithms and different storage formats. The end result of that is that it's literally orders of magnitude faster on large codebases. But to the USER it can be used exactly the same; you could even write a little CVS-to-GIT wrapper which imported your CVS into a git repo and then let you operate on it using gcvs commands the same way you would have operated on real CVS repositories. Just some food for thought Cheers, Kyle Moffett Yes - that's a good example. Git is far more powerful and a different paradigm for CVS. Someone had to think outside the box and come up with a new way of looking at things. I'm trying to do something like that with this idea. To me it make more sense to get rid of file permissions and look at people permissions. It reminds me of a story a friend of mine told about her 4 year old son. The story was that they were driving down the road when they saw a wheel come off a truck. The son said, look mommy, that wheel lost it's truck. To me files are like the wheel. Rather than having the file know all it's owners it makes more sense for the owners to know it's files. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mailp=summer+activities+for+kidscs=bz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Phillip Susi [EMAIL PROTECTED] wrote: Marc Perkel wrote: Kyle - you are still missing the point. chmod goes away. File permissions goes away. Directories as you know them goes away. You are missing the point Marc... open()ing a file will have to perform a number of these pattern matches to decide if it is allowed or not... this would be a HUGE overhead. I don't see it as being any worse that what we have now. To open a file you have to start at the bottom and open each directory and evaluate the permissions on the way to the file. In my system you have to look up the permission of the string at each / separator. Seems to me that every system would have these same steps. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- Kyle Moffett [EMAIL PROTECTED] wrote: Al Viro added to the CC, since he's one of the experts on this stuff and will probably whack me with a LART for explaining it all wrong, or something. :-D Thanks - I appreciate that. Just to catch everyone up on what this thread is about, I'm proposing a new way of looking at file systems where files no longer have permission, owners, or groups, or file attributes. The idea is that people, groups, managers, applications, and other objects have permissions to names that are pointers to files. On Aug 15, 2007, at 16:38:36, Phillip Susi wrote: Kyle Moffett wrote: We've *always* had to do this; that's what chmod -R or setfacl - R are for :-D. The major problem is that the locking and lookup overhead gets really significant if you have to look at the entire directory tree in order to determine the permissions for one single object. I definitely agree that we need better GUIs for managing file permissions, but I don't see how you could modify the kernel in this case to do what you want. I am well aware of that, I'm simply saying that sucks. Doing a recursive chmod or setfacl on a large directory tree is slow as all hell. Doing it in the kernel won't make it any faster. As for hard links, your access would depend on which name you use to access the file. The file itself may still have an acl that grants or denies access to people no matter what name they use, but if it allows inheritance, then which name you access it by will modify the effective acl that it gets. You can't safely preserve POSIX semantics that way. For example, even without *ANY* ability to read /etc/shadow, I can easily ln /etc/ shadow /tmp/shadow, assuming they are on the same filesystem. If the /etc/shadow permissions depend on inherited ACLs to enforce access then that one little command just made your shadow file world- readable/writeable. Oops. Think about it this way: Permissions depend on *what* something is, not *where* it is. Under Linux you can leave the digital equivalent of a $10,000 piece of jewelry lying around in /var/www and not have to worry about it being compromised as long as you set your permissions properly (not that I recommend it). Moving the piece of jewelry around your house does not change what it *is* (and by extension does not change the protection required on it), any more than ln /etc/shadow /tmp/ shadow (or mv) changes what *it* is. If your /house is really extraordinarily secure then you could leave the jewelry lying around as /house/gems.bin with permissions 0777, but if somebody had a back- door to /house (an open fd, a careless typo, etc) then you'd have the same issues. My proposal is the same somewhat. If one put restricting on a specific name to deny access to users then that denial follows that filename even if it is copied or moved. However if a file has no specific restrictions and is in a restricted directory then the file inherits the restrictions and permissions of the new directory based on where it is. If you don't want your jewlery laying around then don't put a copy of it in a folder where users have access to it. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thinking outside the box on file systems
--- [EMAIL PROTECTED] wrote: On Wed, 15 Aug 2007 13:50:17 PDT, Marc Perkel said: I don't see it as being any worse that what we have now. To open a file you have to start at the bottom and open each directory and evaluate the permissions on the way to the file. In my system you have to look up the permission of the string at each / separator. Seems to me that every system would have these same steps. No - you need to look at the *whole* string - that's the whole *point* of your system, remember? Just a few msgs back, you gave a nice example of having a file with \ in the name rather than / because it came from a Windows user. So you *do* need to check *every* pattern against the filename, because it *could* match. In a system with several hundred thousand or more patterns, that could be painful. Also, you need to figure out how to deal with all the various silly corner cases that people will end up trying to do. Consider the rules: peter '*a*' can create peter '*b*' cannot create Peter tries to create 'foo-ab-bar' - is he allowed to or not? First - I'm proposing a concept, not writing the implementation of the concept. You are asking what happens when someone write conflicting rules. That depends on how you implement it. Conflicting rules can cause unpredictable results. It may be as simple as first rule wins. Or it may require all the rules to be true. In the above example I would say it is not allowed because it matches a denial condition. The point is that one can choose any rule system they want and the rules applies to the names of the files and the permissions of the users. For an exersize, either write a program or do by hand: Create a list of patterns that correctly express the ownership and permissions of *every* file on your current Linux box. Then repeat on a large box with multiple users and a few Oracle databases or webservers. Then write a small tool, that given that list, a username, a filename, and the operation (read, write, open, unlink, etc), says Yes or No. Then run 'strace /bin/ls' in a large directory, take all the filenames listed in the strace output, and see if your tool can answer yes or no fast enough to make 'ls' feasible. Come back when you get that part done, and we'll discuss how it would have to work in the kernel. All you would have to do is create a set of rules that emulates the current rules and you would have the same results. Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Thinking outside the box on file systems
I want to throw out some concepts about a new way of thinking about file systems. But the first thing you have to do is to forget what you know about file systems now. This is a discussion about a new view of looking a file storage that is radically different and it's more easily undersood if you forget a lot of what you know. The idea is to create what seems natural to the user rather than what seems natural to the programmer. For example, if a user has not read or write access to a file then why should they be able to delete the file - or even list the file in the directory? In order to grasp this idea the idea of directory permission as you now know them needs to go away. Imagine that the file system is a database that contains file data, name data, and permission data. Loose the idea that files have an owner and a group or the attributes that we are familiar with. Think instead that users, groups, managers, application, and such are objects and there is a complex rights system that gives access to names that point to file data. For example. If you list a directory you only see the files that you have some rights to and files where you have no rights are invisible to you. If a file is read only to you then you can't delete it either. Having write access to a directory really means that you have file create rights. You can also delete files that you have write access to. You would also allocate permissions to manage file rights like being able to set the rights of inferior users. The ACLs that were added to Linux were a step in the right direction but very incomplete. What should be is a complex permission system that would allow fine grained permissions and inherentance masks to control what permission are granted when someone moves new files into a directory. Instead of just root and users there would be mid level roles where users and objects had management authority over parts of the system and the roles can be defined in a very flexible way. For example, rights might change during "business hours". I want to throw these concepts out there to inspire a new way of thinging and let Linux evolve into a more natural kind of file system rather than staying ture to it's ancient roots. Of course there would be an emulation layer to keep existing apps happy but I think that Linux will never be truly what it could be unless it breaks away from the limitations of the past. Anyhow, I'm going to stop at this just to let these ideas settle in. In my mind there's a lot more detail but let's see where this goes. Marc Perkel Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Thinking outside the box on file systems
I want to throw out some concepts about a new way of thinking about file systems. But the first thing you have to do is to forget what you know about file systems now. This is a discussion about a new view of looking a file storage that is radically different and it's more easily undersood if you forget a lot of what you know. The idea is to create what seems natural to the user rather than what seems natural to the programmer. For example, if a user has not read or write access to a file then why should they be able to delete the file - or even list the file in the directory? In order to grasp this idea the idea of directory permission as you now know them needs to go away. Imagine that the file system is a database that contains file data, name data, and permission data. Loose the idea that files have an owner and a group or the attributes that we are familiar with. Think instead that users, groups, managers, application, and such are objects and there is a complex rights system that gives access to names that point to file data. For example. If you list a directory you only see the files that you have some rights to and files where you have no rights are invisible to you. If a file is read only to you then you can't delete it either. Having write access to a directory really means that you have file create rights. You can also delete files that you have write access to. You would also allocate permissions to manage file rights like being able to set the rights of inferior users. The ACLs that were added to Linux were a step in the right direction but very incomplete. What should be is a complex permission system that would allow fine grained permissions and inherentance masks to control what permission are granted when someone moves new files into a directory. Instead of just root and users there would be mid level roles where users and objects had management authority over parts of the system and the roles can be defined in a very flexible way. For example, rights might change during business hours. I want to throw these concepts out there to inspire a new way of thinging and let Linux evolve into a more natural kind of file system rather than staying ture to it's ancient roots. Of course there would be an emulation layer to keep existing apps happy but I think that Linux will never be truly what it could be unless it breaks away from the limitations of the past. Anyhow, I'm going to stop at this just to let these ideas settle in. In my mind there's a lot more detail but let's see where this goes. Marc Perkel Marc Perkel Junk Email Filter dot com http://www.junkemailfilter.com Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Woke up to a crashed kernet this morning - nVidia is crap
OK - so the driver I downloaded from nVidia to fix their problem I was having with the video installed drivers for everything? I'm really getting to dislike nVidia. --- Michal Piotrowski <[EMAIL PROTECTED]> wrote: > > Nvidia binary crap > > "When you are using a binary driver, the kernel > is "tainted", > which means that the source > of possible problems may be unrelated to the kernel > code (see > https://secure-support. > novell.com/KanisaPlatform/Publishing/250/3582750_f.SAL_Public.html > for more de- > tails). You can check whether or not the kernel was > tainted when the > problem occurred by > looking at the corresponding error message. If can > you see something > similar to the following > line: > EIP: 0060:[]Tainted: P > VLI > (the word Tainted is crucial here), the kernel was > tainted and most > probably the kernel > developers will not be able to help you. In that > case you should try > to reproduce the problem > without the binary driver loaded. Moreover, if the > problem does not > occur without it, you > should send a bug report to the creators of the > binary driver and ask > them to ï¬x it. > In the ï¬le Documentation/oops-tracing.txt, > included in the kernel > sources, there is a > list of reasons why the kernel can be considered as > tainted. As > follows from this document, > the presence of a binary module is not the only > possible reason of > tainting the kernel, but > in practice it turns out to be the most frequent > one. Generally, you > should avoid reporting > problems in tainted kernels to the LKML (or to the > kernel developers > in general) and the > problems related to binary drivers should be > reported to their providers." > > -- Linux Kernel Tester's Guide > > Regards, > Michal > > -- > LOG > http://www.stardust.webpages.pl/log/ > Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Woke up to a crashed kernet this morning
Found this in the log. Running 2.6.22,1,41,fc7 - I had just upgraded the kernel last night using yum. And - I was running a lot of backups using rsync and was backing up to a usb connected drive. I'm not sure which event triggered it but I'm guessing the latter in that it's something I rarely do using usb. Aug 2 01:54:09 bigdog kernel: [ cut here ] Aug 2 01:54:10 bigdog kernel: kernel BUG at fs/jbd/journal.c:568! Aug 2 01:54:10 bigdog kernel: invalid opcode: [1] SMP Aug 2 01:54:10 bigdog kernel: last sysfs file: /block/sde/size Aug 2 01:54:10 bigdog kernel: CPU 0 Aug 2 01:54:10 bigdog kernel: Modules linked in: iptable_filter ip_tables x_tables nvidia(P)(U) autofs4 ipv6 cpufreq_ondemand dm_mirror dm_mod raid0 video sbs button dock battery ac lp loop sr_mod cdrom snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer firewire_ohci snd soundcore snd_page_alloc k8temp firewire_core crc_itu_t hwmon rtc_cmos parport_pc forcedeth i2c_nforce2 shpchp serio_raw pata_amd floppy parport i2c_core sg usb_storage sata_nv ata_generic libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd Aug 2 01:54:10 bigdog kernel: Pid: 10240, comm: kjournald Tainted: P 2.6.22.1-41.fc7 #1 Aug 2 01:54:10 bigdog kernel: RIP: 0010:[] [] :jbd:journal_next_log_block+0x47/0x91 Aug 2 01:54:10 bigdog kernel: RSP: 0018:8100bfe53e20 EFLAGS: 00010286 Aug 2 01:54:10 bigdog kernel: RAX: 0060 RBX: 8100bf841c00 RCX: 8136c308 Aug 2 01:54:10 bigdog kernel: RDX: 0001 RSI: 0082 RDI: Aug 2 01:54:10 bigdog kernel: RBP: 8100bfe53e90 R08: 8136c308 R09: Aug 2 01:54:10 bigdog kernel: R10: 0046 R11: 8101b6c2 R12: 81000fd5ad80 Aug 2 01:54:10 bigdog kernel: R13: 810007bc6e40 R14: 01fb R15: 81008ebadf94 Aug 2 01:54:11 bigdog kernel: FS: 2aac8f20() GS:813ad000() knlGS:f7fe26c0 Aug 2 01:54:11 bigdog kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b Aug 2 01:54:11 bigdog kernel: CR2: 2aac6000 CR3: 000127dda000 CR4: 06e0 Aug 2 01:54:11 bigdog kernel: Process kjournald (pid: 10240, threadinfo 8100bfe52000, task 810107262000) Aug 2 01:54:11 bigdog kernel: Stack: 810007bc6e40 81006d89dde0 8100bf841c00 88029977 Aug 2 01:54:11 bigdog kernel: 8100bfe5 01f0bfe53e98 006c 008f Aug 2 01:54:11 bigdog kernel: 810107262000 810443fd 8100bfe53e78 Aug 2 01:54:11 bigdog kernel: Call Trace: Aug 2 01:54:11 bigdog kernel: [] :jbd:journal_commit_transaction+0x77d/0x106e Aug 2 01:54:11 bigdog kernel: [] autoremove_wake_function+0x0/0x2e Aug 2 01:54:11 bigdog kernel: [] :jbd:kjournald+0xb9/0x212 Aug 2 01:54:11 bigdog kernel: [] autoremove_wake_function+0x0/0x2e Aug 2 01:54:11 bigdog kernel: [] :jbd:kjournald+0x0/0x212 Aug 2 01:54:11 bigdog kernel: [] kthread+0x47/0x73 Aug 2 01:54:11 bigdog kernel: [] child_rip+0xa/0x12 Aug 2 01:54:11 bigdog kernel: [] kthread+0x0/0x73 Aug 2 01:54:11 bigdog kernel: [] child_rip+0x0/0x12 Aug 2 01:54:11 bigdog kernel: Aug 2 01:54:11 bigdog kernel: Aug 2 01:54:11 bigdog kernel: Code: 0f 0b eb fe 48 8b b3 08 01 00 00 48 ff 8b 18 01 00 00 48 8d Aug 2 01:54:11 bigdog kernel: RIP [] :jbd:journal_next_log_block+0x47/0x91 Aug 2 01:54:11 bigdog kernel: RSP And the hardware config: Aug 2 06:36:12 bigdog syslogd 1.4.2: restart. Aug 2 06:36:12 bigdog kernel: klogd 1.4.2, log source = /proc/kmsg started. Aug 2 06:36:12 bigdog kernel: Linux version 2.6.22.1-41.fc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Fri Jul 27 18:21:43 EDT 2007 Aug 2 06:36:12 bigdog kernel: Command line: ro root=LABEL=/ pci=nommconf vga=794 iommu=soft Aug 2 06:36:12 bigdog kernel: BIOS-provided physical RAM map: Aug 2 06:36:12 bigdog kernel: BIOS-e820: - 0009f000 (usable) Aug 2 06:36:12 bigdog kernel: BIOS-e820: 0009f000 - 000a (reserved) Aug 2 06:36:12 bigdog kernel: BIOS-e820: 000f - 0010 (reserved) Aug 2 06:36:12 bigdog kernel: BIOS-e820: 0010 - bfee (usable) Aug 2 06:36:12 bigdog kernel: BIOS-e820: bfee - bfee3000 (ACPI NVS) Aug 2 06:36:12 bigdog kernel: BIOS-e820: bfee3000 - bfef (ACPI data) Aug 2 06:36:12 bigdog kernel: BIOS-e820: bfef - bff0 (reserved) Aug 2 06:36:12 bigdog kernel: BIOS-e820: c000 - d000 (reserved) Aug 2 06:36:12 bigdog kernel: BIOS-e820: e000 - f000 (reserved) Aug 2 06:36:12 bigdog kernel: BIOS-e820: fec0 - 0001 (reserved) Aug 2 06:36:12 bigdog kernel: BIOS-e820: 0001 - 00013000 (usable) Aug 2
Woke up to a crashed kernet this morning
Found this in the log. Running 2.6.22,1,41,fc7 - I had just upgraded the kernel last night using yum. And - I was running a lot of backups using rsync and was backing up to a usb connected drive. I'm not sure which event triggered it but I'm guessing the latter in that it's something I rarely do using usb. Aug 2 01:54:09 bigdog kernel: [ cut here ] Aug 2 01:54:10 bigdog kernel: kernel BUG at fs/jbd/journal.c:568! Aug 2 01:54:10 bigdog kernel: invalid opcode: [1] SMP Aug 2 01:54:10 bigdog kernel: last sysfs file: /block/sde/size Aug 2 01:54:10 bigdog kernel: CPU 0 Aug 2 01:54:10 bigdog kernel: Modules linked in: iptable_filter ip_tables x_tables nvidia(P)(U) autofs4 ipv6 cpufreq_ondemand dm_mirror dm_mod raid0 video sbs button dock battery ac lp loop sr_mod cdrom snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer firewire_ohci snd soundcore snd_page_alloc k8temp firewire_core crc_itu_t hwmon rtc_cmos parport_pc forcedeth i2c_nforce2 shpchp serio_raw pata_amd floppy parport i2c_core sg usb_storage sata_nv ata_generic libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd Aug 2 01:54:10 bigdog kernel: Pid: 10240, comm: kjournald Tainted: P 2.6.22.1-41.fc7 #1 Aug 2 01:54:10 bigdog kernel: RIP: 0010:[8802cd3a] [8802cd3a] :jbd:journal_next_log_block+0x47/0x91 Aug 2 01:54:10 bigdog kernel: RSP: 0018:8100bfe53e20 EFLAGS: 00010286 Aug 2 01:54:10 bigdog kernel: RAX: 0060 RBX: 8100bf841c00 RCX: 8136c308 Aug 2 01:54:10 bigdog kernel: RDX: 0001 RSI: 0082 RDI: Aug 2 01:54:10 bigdog kernel: RBP: 8100bfe53e90 R08: 8136c308 R09: Aug 2 01:54:10 bigdog kernel: R10: 0046 R11: 8101b6c2 R12: 81000fd5ad80 Aug 2 01:54:10 bigdog kernel: R13: 810007bc6e40 R14: 01fb R15: 81008ebadf94 Aug 2 01:54:11 bigdog kernel: FS: 2aac8f20() GS:813ad000() knlGS:f7fe26c0 Aug 2 01:54:11 bigdog kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b Aug 2 01:54:11 bigdog kernel: CR2: 2aac6000 CR3: 000127dda000 CR4: 06e0 Aug 2 01:54:11 bigdog kernel: Process kjournald (pid: 10240, threadinfo 8100bfe52000, task 810107262000) Aug 2 01:54:11 bigdog kernel: Stack: 810007bc6e40 81006d89dde0 8100bf841c00 88029977 Aug 2 01:54:11 bigdog kernel: 8100bfe5 01f0bfe53e98 006c 008f Aug 2 01:54:11 bigdog kernel: 810107262000 810443fd 8100bfe53e78 Aug 2 01:54:11 bigdog kernel: Call Trace: Aug 2 01:54:11 bigdog kernel: [88029977] :jbd:journal_commit_transaction+0x77d/0x106e Aug 2 01:54:11 bigdog kernel: [810443fd] autoremove_wake_function+0x0/0x2e Aug 2 01:54:11 bigdog kernel: [8802d0e3] :jbd:kjournald+0xb9/0x212 Aug 2 01:54:11 bigdog kernel: [810443fd] autoremove_wake_function+0x0/0x2e Aug 2 01:54:11 bigdog kernel: [8802d02a] :jbd:kjournald+0x0/0x212 Aug 2 01:54:11 bigdog kernel: [810442a8] kthread+0x47/0x73 Aug 2 01:54:11 bigdog kernel: [8100a978] child_rip+0xa/0x12 Aug 2 01:54:11 bigdog kernel: [81044261] kthread+0x0/0x73 Aug 2 01:54:11 bigdog kernel: [8100a96e] child_rip+0x0/0x12 Aug 2 01:54:11 bigdog kernel: Aug 2 01:54:11 bigdog kernel: Aug 2 01:54:11 bigdog kernel: Code: 0f 0b eb fe 48 8b b3 08 01 00 00 48 ff 8b 18 01 00 00 48 8d Aug 2 01:54:11 bigdog kernel: RIP [8802cd3a] :jbd:journal_next_log_block+0x47/0x91 Aug 2 01:54:11 bigdog kernel: RSP 8100bfe53e20 And the hardware config: Aug 2 06:36:12 bigdog syslogd 1.4.2: restart. Aug 2 06:36:12 bigdog kernel: klogd 1.4.2, log source = /proc/kmsg started. Aug 2 06:36:12 bigdog kernel: Linux version 2.6.22.1-41.fc7 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Fri Jul 27 18:21:43 EDT 2007 Aug 2 06:36:12 bigdog kernel: Command line: ro root=LABEL=/ pci=nommconf vga=794 iommu=soft Aug 2 06:36:12 bigdog kernel: BIOS-provided physical RAM map: Aug 2 06:36:12 bigdog kernel: BIOS-e820: - 0009f000 (usable) Aug 2 06:36:12 bigdog kernel: BIOS-e820: 0009f000 - 000a (reserved) Aug 2 06:36:12 bigdog kernel: BIOS-e820: 000f - 0010 (reserved) Aug 2 06:36:12 bigdog kernel: BIOS-e820: 0010 - bfee (usable) Aug 2 06:36:12 bigdog kernel: BIOS-e820: bfee - bfee3000 (ACPI NVS) Aug 2 06:36:12 bigdog kernel: BIOS-e820: bfee3000 - bfef (ACPI data) Aug 2 06:36:12 bigdog kernel: BIOS-e820: bfef - bff0 (reserved) Aug 2 06:36:12 bigdog kernel: BIOS-e820: c000 - d000 (reserved) Aug 2 06:36:12 bigdog kernel: BIOS-e820: e000 -
Re: Woke up to a crashed kernet this morning - nVidia is crap
OK - so the driver I downloaded from nVidia to fix their problem I was having with the video installed drivers for everything? I'm really getting to dislike nVidia. --- Michal Piotrowski [EMAIL PROTECTED] wrote: Nvidia binary crap When you are using a binary driver, the kernel is tainted, which means that the source of possible problems may be unrelated to the kernel code (see https://secure-support. novell.com/KanisaPlatform/Publishing/250/3582750_f.SAL_Public.html for more de- tails). You can check whether or not the kernel was tainted when the problem occurred by looking at the corresponding error message. If can you see something similar to the following line: EIP: 0060:[c046c7c3]Tainted: P VLI (the word Tainted is crucial here), the kernel was tainted and most probably the kernel developers will not be able to help you. In that case you should try to reproduce the problem without the binary driver loaded. Moreover, if the problem does not occur without it, you should send a bug report to the creators of the binary driver and ask them to ï¬x it. In the ï¬le Documentation/oops-tracing.txt, included in the kernel sources, there is a list of reasons why the kernel can be considered as tainted. As follows from this document, the presence of a binary module is not the only possible reason of tainting the kernel, but in practice it turns out to be the most frequent one. Generally, you should avoid reporting problems in tainted kernels to the LKML (or to the kernel developers in general) and the problems related to binary drivers should be reported to their providers. -- Linux Kernel Tester's Guide Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVidia Driver Support - 1680x1050 mode
--- Carlo Wood <[EMAIL PROTECTED]> wrote: > Or use the same hardware as me (and debian)-- and > read on my home page how > I got things working :p > > hikaru:/usr/lib>dpkg -l | grep nvidia > ii nvidia-glx > 100.14.11-0 NVIDIA > binary Xorg driver > ii nvidia-glx-dev > 100.14.11-0 > NVIDIA binary Xorg driver development files > ii nvidia-kernel-2.6-amd64 > 100.14.11+beta >NVIDIA binary kernel module for 2.6 series c > ii nvidia-kernel-2.6.18-4-amd64 > 100.14.11+beta NVIDIA binary kernel module for > Linux 2.6.18 > ii > nvidia-kernel-2.6.22-rc5-agp1-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64 > 100.14.11+beta NVIDIA binary kernel module for > Linux 2.6.22 > > -- > Carlo Wood <[EMAIL PROTECTED]> > > PS I use two of my Samsung SyncMaster 205BW > (1650x1050) as dual head >on an ASUS EN8600 GTS (dual-head). You need > nvidia's beta drivers >(>= 100.14.06) for that to work though. > > Yes - I downloaded the drivers from nVidia and everything works now. Thanks to everyone for your help. Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVidia Driver Support - 1680x1050 mode
--- Carlo Wood [EMAIL PROTECTED] wrote: Or use the same hardware as me (and debian)-- and read on my home page how I got things working :p hikaru:/usr/libdpkg -l | grep nvidia ii nvidia-glx 100.14.11-0 NVIDIA binary Xorg driver ii nvidia-glx-dev 100.14.11-0 NVIDIA binary Xorg driver development files ii nvidia-kernel-2.6-amd64 100.14.11+beta NVIDIA binary kernel module for 2.6 series c ii nvidia-kernel-2.6.18-4-amd64 100.14.11+beta NVIDIA binary kernel module for Linux 2.6.18 ii nvidia-kernel-2.6.22-rc5-agp1-188e1f81ba31af1b65a2f3611df4c670b092bbac-amd64 100.14.11+beta NVIDIA binary kernel module for Linux 2.6.22 -- Carlo Wood [EMAIL PROTECTED] PS I use two of my Samsung SyncMaster 205BW (1650x1050) as dual head on an ASUS EN8600 GTS (dual-head). You need nvidia's beta drivers (= 100.14.06) for that to work though. Yes - I downloaded the drivers from nVidia and everything works now. Thanks to everyone for your help. Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool. http://autos.yahoo.com/carfinder/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVidia Driver Support - 1680x1050 mode
--- Kyle Moffett <[EMAIL PROTECTED]> wrote: > Marc, please choose a more appropriate list next > time. LKML is not > for user questions about "Why doesn't my monitor+GPU > work?" > > On Jun 27, 2007, at 05:49:20, Daniel J Blueman > wrote: > > On 27 Jun, 04:40, Marc Perkel <[EMAIL PROTECTED]> > wrote: > >> Trying to get my Asus M2NPV-VM motherboard and my > Samsung > >> SyncMaster 215tw Digital to work in 1680x1050 > mode but 1280x1024 > >> is the most I can get. Chip Set is GeForce 6150. > >> > >> Looking in Xorg.0.log it ssems to think that the > panel size is > >> 1280x1024 in spite of my setting telling it > differently. > >> > >> Sorry if this is off topic but I thought that the > smart people > >> would be here. In Windows I just plug it in and > it works. So I > >> figure Linux should work too. :) > > > > Wrong list, but anyway... > > > > If you're using a DVI cable, ensure it is > dual-link. > > Uhh, no; 1680x1050 does not require a dual-link DVI > port/cable. As > to a good GPU which "Just Works(TM)" out of the box > and still has at > least passable render performance (although not for > some modern > games), the R200-series Radeon cards (listed below) > work extremely > well. They even support a 3d-accelerated > merged-framebuffer Xinerama- > style; you can split a 3d-accelerated window across > both monitors. > > R200-series cards: >R200: Radeon 8500/8500LE/9100, FireGL 8700/8800 >rv250: Radeon 9000/9000Pro >rv280: Radeon 9200/9250/9200SE > > More info here: >http://dri.freedesktop.org/wiki/ > ATIRadeon#head-9161ac9470497d94f1a4f79794697347b20d5170 > > Cheers, > Kyle Moffett > Quite frankly, I don't understand why digital LCD monitor even have scan rates in the first place. It's not a CRT that actually has an electron beam. You would thing that it would have a digital interface where the computer told the monitor what to draw and the monitor deals with it. Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVidia Driver Support - 1680x1050 mode
If I were to try a different brand of video card to get 1680x1050 where the main criteria was "just works", what brand should I get? --- Michael Lothian <[EMAIL PROTECTED]> wrote: > OK where to start? > > Firstly this is really the wrong list your writing > to. Chances are > you'll be wanting to ask your question at > http://www.nvnews.net/vbulletin/forumdisplay.php?s==14 > if your > using the Nvidia Blob otherwise if your using the 2D > only NV driver > then you should really aim your question at the Xorg > guys and gals > > Secondly how exactly did you tell it differently? > > Chances are your /etc/conf.d/xorg.conf is wrong if > you were using the > latest X server with the latest binary blob (nvidia > driver) chances > are it would detect the highest resolution and set > it for you. The > program nvidia-xconfig should fix the file for you. > > Oh and thirdly do you really think it just works on > windows is a good > incentive to get people to help you? Yes it should > work out the box > but unfortunately the world of Linux 3D drivers is > mostly dominated > with company's that prefers keeping their drivers in > a black box and > hopefully in the not too distant future the neuveau > project might > remedy this. > > Any way I hope this e-mail both helps with your > problems and adds to > your understanding of how things work. The kernel > mailing list is for > kernel issues (which include rivafb and nvidiafb but > not nv and nvidia > 3d issues) so if you ever plug in a hard drive and > it's not working at > full speed or something along those lines that's > when you should call. > > Cheers > > Mike > > On 27/06/07, Marc Perkel <[EMAIL PROTECTED]> wrote: > > Trying to get my Asus M2NPV-VM motherboard and my > > Samsung SyncMaster 215tw Digital to work in > 1680x1050 > > mode but 1280x1024 is the most I can get. Chip Set > is > > GeForce 6150. > > > > Looking in Xorg.0.log it ssems to think that the > panel > > size is 1280x1024 in spite of my setting telling > it > > differently. > > > > Sorry if this is off topic but I thought that the > > smart people would be here. In Windows I just plug > it > > in and it works. So I figure Linux should work > too. :) > Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=list=396545433 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVidia Driver Support - 1680x1050 mode
Thanks - I'll try looking there. --- Michael Lothian <[EMAIL PROTECTED]> wrote: > OK where to start? > > Firstly this is really the wrong list your writing > to. Chances are > you'll be wanting to ask your question at > http://www.nvnews.net/vbulletin/forumdisplay.php?s==14 > if your > using the Nvidia Blob otherwise if your using the 2D > only NV driver > then you should really aim your question at the Xorg > guys and gals > > Secondly how exactly did you tell it differently? > > Chances are your /etc/conf.d/xorg.conf is wrong if > you were using the > latest X server with the latest binary blob (nvidia > driver) chances > are it would detect the highest resolution and set > it for you. The > program nvidia-xconfig should fix the file for you. > > Oh and thirdly do you really think it just works on > windows is a good > incentive to get people to help you? Yes it should > work out the box > but unfortunately the world of Linux 3D drivers is > mostly dominated > with company's that prefers keeping their drivers in > a black box and > hopefully in the not too distant future the neuveau > project might > remedy this. > > Any way I hope this e-mail both helps with your > problems and adds to > your understanding of how things work. The kernel > mailing list is for > kernel issues (which include rivafb and nvidiafb but > not nv and nvidia > 3d issues) so if you ever plug in a hard drive and > it's not working at > full speed or something along those lines that's > when you should call. > > Cheers > > Mike > > On 27/06/07, Marc Perkel <[EMAIL PROTECTED]> wrote: > > Trying to get my Asus M2NPV-VM motherboard and my > > Samsung SyncMaster 215tw Digital to work in > 1680x1050 > > mode but 1280x1024 is the most I can get. Chip Set > is > > GeForce 6150. > > > > Looking in Xorg.0.log it ssems to think that the > panel > > size is 1280x1024 in spite of my setting telling > it > > differently. > > > > Sorry if this is off topic but I thought that the > > smart people would be here. In Windows I just plug > it > > in and it works. So I figure Linux should work > too. :) > Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVidia Driver Support - 1680x1050 mode
Thanks - I'll try looking there. --- Michael Lothian [EMAIL PROTECTED] wrote: OK where to start? Firstly this is really the wrong list your writing to. Chances are you'll be wanting to ask your question at http://www.nvnews.net/vbulletin/forumdisplay.php?s=forumid=14 if your using the Nvidia Blob otherwise if your using the 2D only NV driver then you should really aim your question at the Xorg guys and gals Secondly how exactly did you tell it differently? Chances are your /etc/conf.d/xorg.conf is wrong if you were using the latest X server with the latest binary blob (nvidia driver) chances are it would detect the highest resolution and set it for you. The program nvidia-xconfig should fix the file for you. Oh and thirdly do you really think it just works on windows is a good incentive to get people to help you? Yes it should work out the box but unfortunately the world of Linux 3D drivers is mostly dominated with company's that prefers keeping their drivers in a black box and hopefully in the not too distant future the neuveau project might remedy this. Any way I hope this e-mail both helps with your problems and adds to your understanding of how things work. The kernel mailing list is for kernel issues (which include rivafb and nvidiafb but not nv and nvidia 3d issues) so if you ever plug in a hard drive and it's not working at full speed or something along those lines that's when you should call. Cheers Mike On 27/06/07, Marc Perkel [EMAIL PROTECTED] wrote: Trying to get my Asus M2NPV-VM motherboard and my Samsung SyncMaster 215tw Digital to work in 1680x1050 mode but 1280x1024 is the most I can get. Chip Set is GeForce 6150. Looking in Xorg.0.log it ssems to think that the panel size is 1280x1024 in spite of my setting telling it differently. Sorry if this is off topic but I thought that the smart people would be here. In Windows I just plug it in and it works. So I figure Linux should work too. :) Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVidia Driver Support - 1680x1050 mode
If I were to try a different brand of video card to get 1680x1050 where the main criteria was just works, what brand should I get? --- Michael Lothian [EMAIL PROTECTED] wrote: OK where to start? Firstly this is really the wrong list your writing to. Chances are you'll be wanting to ask your question at http://www.nvnews.net/vbulletin/forumdisplay.php?s=forumid=14 if your using the Nvidia Blob otherwise if your using the 2D only NV driver then you should really aim your question at the Xorg guys and gals Secondly how exactly did you tell it differently? Chances are your /etc/conf.d/xorg.conf is wrong if you were using the latest X server with the latest binary blob (nvidia driver) chances are it would detect the highest resolution and set it for you. The program nvidia-xconfig should fix the file for you. Oh and thirdly do you really think it just works on windows is a good incentive to get people to help you? Yes it should work out the box but unfortunately the world of Linux 3D drivers is mostly dominated with company's that prefers keeping their drivers in a black box and hopefully in the not too distant future the neuveau project might remedy this. Any way I hope this e-mail both helps with your problems and adds to your understanding of how things work. The kernel mailing list is for kernel issues (which include rivafb and nvidiafb but not nv and nvidia 3d issues) so if you ever plug in a hard drive and it's not working at full speed or something along those lines that's when you should call. Cheers Mike On 27/06/07, Marc Perkel [EMAIL PROTECTED] wrote: Trying to get my Asus M2NPV-VM motherboard and my Samsung SyncMaster 215tw Digital to work in 1680x1050 mode but 1280x1024 is the most I can get. Chip Set is GeForce 6150. Looking in Xorg.0.log it ssems to think that the panel size is 1280x1024 in spite of my setting telling it differently. Sorry if this is off topic but I thought that the smart people would be here. In Windows I just plug it in and it works. So I figure Linux should work too. :) Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545433 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: NVidia Driver Support - 1680x1050 mode
--- Kyle Moffett [EMAIL PROTECTED] wrote: Marc, please choose a more appropriate list next time. LKML is not for user questions about Why doesn't my monitor+GPU work? On Jun 27, 2007, at 05:49:20, Daniel J Blueman wrote: On 27 Jun, 04:40, Marc Perkel [EMAIL PROTECTED] wrote: Trying to get my Asus M2NPV-VM motherboard and my Samsung SyncMaster 215tw Digital to work in 1680x1050 mode but 1280x1024 is the most I can get. Chip Set is GeForce 6150. Looking in Xorg.0.log it ssems to think that the panel size is 1280x1024 in spite of my setting telling it differently. Sorry if this is off topic but I thought that the smart people would be here. In Windows I just plug it in and it works. So I figure Linux should work too. :) Wrong list, but anyway... If you're using a DVI cable, ensure it is dual-link. Uhh, no; 1680x1050 does not require a dual-link DVI port/cable. As to a good GPU which Just Works(TM) out of the box and still has at least passable render performance (although not for some modern games), the R200-series Radeon cards (listed below) work extremely well. They even support a 3d-accelerated merged-framebuffer Xinerama- style; you can split a 3d-accelerated window across both monitors. R200-series cards: R200: Radeon 8500/8500LE/9100, FireGL 8700/8800 rv250: Radeon 9000/9000Pro rv280: Radeon 9200/9250/9200SE More info here: http://dri.freedesktop.org/wiki/ ATIRadeon#head-9161ac9470497d94f1a4f79794697347b20d5170 Cheers, Kyle Moffett Quite frankly, I don't understand why digital LCD monitor even have scan rates in the first place. It's not a CRT that actually has an electron beam. You would thing that it would have a digital interface where the computer told the monitor what to draw and the monitor deals with it. Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NVidia Driver Support - 1680x1050 mode
Trying to get my Asus M2NPV-VM motherboard and my Samsung SyncMaster 215tw Digital to work in 1680x1050 mode but 1280x1024 is the most I can get. Chip Set is GeForce 6150. Looking in Xorg.0.log it ssems to think that the panel size is 1280x1024 in spite of my setting telling it differently. Sorry if this is off topic but I thought that the smart people would be here. In Windows I just plug it in and it works. So I figure Linux should work too. :) Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
NVidia Driver Support - 1680x1050 mode
Trying to get my Asus M2NPV-VM motherboard and my Samsung SyncMaster 215tw Digital to work in 1680x1050 mode but 1280x1024 is the most I can get. Chip Set is GeForce 6150. Looking in Xorg.0.log it ssems to think that the panel size is 1280x1024 in spite of my setting telling it differently. Sorry if this is off topic but I thought that the smart people would be here. In Windows I just plug it in and it works. So I figure Linux should work too. :) Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How would I do this? (expert tricks) OT
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Jun 19 2007 10:14, Marc Perkel wrote:
> >>
> >> tcpdump -lni any port 25
> >> iptables -p tcp --dport 25 -j NFQUEUE
> >> ...
> >>
> >
> >Thanks Jan, but I'm not sure it answers my
> question.
>
> There's more than one way to do it.
>
> One is...
> tcpdump -lni eth0 tcp [extra operands to match SYN
> packets] |
> myprogram
>
> a longer one is to write your own netfilter
> userspace program
> that receives the TCP SYNs (by means of -j NFQUEUE)
> and does
> take action.
>
> Another one is to use -j LOG and let your program
> parse
> down /var/log/firewall. Like
>
> iptables -A INPUT -p tcp --dport 25 --syn -j LOG
> --log-prefix "[evil]"
> tail -f /var/log/firewall | grep '^\[evil\]' |
> myscript
>
> myscript:
> #!/usr/bin/perl
>
> while (defined(my $line = <>)) {
> my($ip) = ($line =~ /SRC=(\S+)/);
> # Do something
> }
>
> >I want to run a script every time a connection
> attempt is made in real time
>
> The scripts runs constantly, preferably.
>
> >with the IP address as a parameter to the script.
> How would I do that? Suppose
> >my script is:
> >
> >iplog
> >
> >
> >
> >
> >
>
>
> >Take the Internet to Go: Yahoo!Go puts the Internet
> in your pocket: mail, news, photos & more.
> >http://mobile.yahoo.com/go?refer=1GNXIC
> >
Thanks Jan,
I think what you sent me is workable. I noticed it
goes to the file /var/log/messages. Is there a way to
make it go to a specific file? Thanks a lot for your
help. I've been experimenting with some new and very
interesting ways to catch spam and this could be yet
another breakthrough.
Shape Yahoo! in your own image. Join our Network Research Panel today!
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How would I do this? (expert tricks) OT
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Jun 19 2007 09:48, Marc Perkel wrote: > > > >I have a server with port 25 closed. I was to be > able > >to run a script every time someone tries to connect > to > >port 25, but from the outside the port remains > closed. > >I need the script that I'm going to run get the IP > >address that tried to connect. > > > >I know it's off topic but it's part of an > experiment > >to stop spam. > > tcpdump -lni any port 25 > iptables -p tcp --dport 25 -j NFQUEUE > ... > Thanks Jan, but I'm not sure it answers my question. I want to run a script every time a connection attempt is made in real time with the IP address as a parameter to the script. How would I do that? Suppose my script is: iplog Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How would I do this? (expert tricks) OT
I have a server with port 25 closed. I was to be able to run a script every time someone tries to connect to port 25, but from the outside the port remains closed. I need the script that I'm going to run get the IP address that tried to connect. I know it's off topic but it's part of an experiment to stop spam. Thanks in advance. Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail=graduation+gifts=bz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How would I do this? (expert tricks) OT
I have a server with port 25 closed. I was to be able to run a script every time someone tries to connect to port 25, but from the outside the port remains closed. I need the script that I'm going to run get the IP address that tried to connect. I know it's off topic but it's part of an experiment to stop spam. Thanks in advance. Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mailp=graduation+giftscs=bz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How would I do this? (expert tricks) OT
--- Jan Engelhardt [EMAIL PROTECTED] wrote: On Jun 19 2007 09:48, Marc Perkel wrote: I have a server with port 25 closed. I was to be able to run a script every time someone tries to connect to port 25, but from the outside the port remains closed. I need the script that I'm going to run get the IP address that tried to connect. I know it's off topic but it's part of an experiment to stop spam. tcpdump -lni any port 25 iptables -p tcp --dport 25 -j NFQUEUE ... Thanks Jan, but I'm not sure it answers my question. I want to run a script every time a connection attempt is made in real time with the IP address as a parameter to the script. How would I do that? Suppose my script is: iplog ipaddress Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos more. http://mobile.yahoo.com/go?refer=1GNXIC - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How would I do this? (expert tricks) OT
--- Jan Engelhardt [EMAIL PROTECTED] wrote:
On Jun 19 2007 10:14, Marc Perkel wrote:
tcpdump -lni any port 25
iptables -p tcp --dport 25 -j NFQUEUE
...
Thanks Jan, but I'm not sure it answers my
question.
There's more than one way to do it.
One is...
tcpdump -lni eth0 tcp [extra operands to match SYN
packets] |
myprogram
a longer one is to write your own netfilter
userspace program
that receives the TCP SYNs (by means of -j NFQUEUE)
and does
take action.
Another one is to use -j LOG and let your program
parse
down /var/log/firewall. Like
iptables -A INPUT -p tcp --dport 25 --syn -j LOG
--log-prefix [evil]
tail -f /var/log/firewall | grep '^\[evil\]' |
myscript
myscript:
#!/usr/bin/perl
while (defined(my $line = )) {
my($ip) = ($line =~ /SRC=(\S+)/);
# Do something
}
I want to run a script every time a connection
attempt is made in real time
The scripts runs constantly, preferably.
with the IP address as a parameter to the script.
How would I do that? Suppose
my script is:
iplog ipaddress
Take the Internet to Go: Yahoo!Go puts the Internet
in your pocket: mail, news, photos more.
http://mobile.yahoo.com/go?refer=1GNXIC
Thanks Jan,
I think what you sent me is workable. I noticed it
goes to the file /var/log/messages. Is there a way to
make it go to a specific file? Thanks a lot for your
help. I've been experimenting with some new and very
interesting ways to catch spam and this could be yet
another breakthrough.
Shape Yahoo! in your own image. Join our Network Research Panel today!
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Instead of GPL License - Why not LKL? (Linux Kernel License)
--- Kevin Bowling <[EMAIL PROTECTED]> wrote: > > If I'm not mistaken, the OP is suggesting that the > name simply be > changed from GPL to LKL to avoid confusion of GPL2 > vs GPL3. Same > verbiage, different name. If these FSF loonies keep > cutting into our > corner of pragmatism, I am inclined to agree :-). > Yes - that is exactly what I'm suggesting. If the agreement is the same but the name of the agreement changes I don't think you would have that much of a transition. GPL2=LKL. But the confusion created by FSF would go away. If Linux is staying with GPL2 then this would signal to the world that there's a fork and that Linux is going in a different direction. Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mail=summer+activities+for+kids=bz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Instead of GPL License - Why not LKL? (Linux Kernel License)
--- Glauber de Oliveira Costa <[EMAIL PROTECTED]> wrote: > On 6/15/07, Marc Perkel <[EMAIL PROTECTED]> wrote: > > I've been somewhat following the GPL2 vs. GPL3 > debate > > and the problem is that it leads to confusion. > GPL3 is > > nothing like GPL2 and the GPLx leads people to > believe > > that GPL3 is just GPL3 improved. > > > > So - just throwing out the idea that if Linus is > > unhappy with GPL3 that Linux lose the GPLx license > and > > call it the Linux Kernel License or LKL for short. > So > > LKL could equal GPL2. > > It seems it would require agreement by all copyright > holders, much > like the v2->v3 transition would do. If it makes the > 2->3 transition > unfeasible, the same may apply here. Would it still be a problem if the licenses were exactly the same? Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Instead of GPL License - Why not LKL? (Linux Kernel License)
I've been somewhat following the GPL2 vs. GPL3 debate and the problem is that it leads to confusion. GPL3 is nothing like GPL2 and the GPLx leads people to believe that GPL3 is just GPL3 improved. So - just throwing out the idea that if Linus is unhappy with GPL3 that Linux lose the GPLx license and call it the Linux Kernel License or LKL for short. So LKL could equal GPL2. Thoughts? Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Instead of GPL License - Why not LKL? (Linux Kernel License)
I've been somewhat following the GPL2 vs. GPL3 debate and the problem is that it leads to confusion. GPL3 is nothing like GPL2 and the GPLx leads people to believe that GPL3 is just GPL3 improved. So - just throwing out the idea that if Linus is unhappy with GPL3 that Linux lose the GPLx license and call it the Linux Kernel License or LKL for short. So LKL could equal GPL2. Thoughts? Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Instead of GPL License - Why not LKL? (Linux Kernel License)
--- Glauber de Oliveira Costa [EMAIL PROTECTED] wrote: On 6/15/07, Marc Perkel [EMAIL PROTECTED] wrote: I've been somewhat following the GPL2 vs. GPL3 debate and the problem is that it leads to confusion. GPL3 is nothing like GPL2 and the GPLx leads people to believe that GPL3 is just GPL3 improved. So - just throwing out the idea that if Linus is unhappy with GPL3 that Linux lose the GPLx license and call it the Linux Kernel License or LKL for short. So LKL could equal GPL2. It seems it would require agreement by all copyright holders, much like the v2-v3 transition would do. If it makes the 2-3 transition unfeasible, the same may apply here. Would it still be a problem if the licenses were exactly the same? Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Instead of GPL License - Why not LKL? (Linux Kernel License)
--- Kevin Bowling [EMAIL PROTECTED] wrote: If I'm not mistaken, the OP is suggesting that the name simply be changed from GPL to LKL to avoid confusion of GPL2 vs GPL3. Same verbiage, different name. If these FSF loonies keep cutting into our corner of pragmatism, I am inclined to agree :-). Yes - that is exactly what I'm suggesting. If the agreement is the same but the name of the agreement changes I don't think you would have that much of a transition. GPL2=LKL. But the confusion created by FSF would go away. If Linux is staying with GPL2 then this would signal to the world that there's a fork and that Linux is going in a different direction. Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mailp=summer+activities+for+kidscs=bz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 10 Problems?
--- Michael Tokarev <[EMAIL PROTECTED]> wrote: > Jan Engelhardt wrote: > [] > > The other thing is, the bitmap is supposed to be > written out at intervals, > > not at every write, so the extra head movement for > bitmap updates should > > be really low, and not making the tar -xjf process > slower by half a minute. > > Is there a way to tweak the write-bitmap-to-disk > interval? Perhaps > > something in /sys or ye olde /proc. Maybe > linux-raid@ knows 8) > > Hmm. Bitmap is supposed to be written before actual > data write, to mark > the to-be-written areas of the array as "being > written", so that those > areas can be detected and recovered in case of power > failure during > actual write. > > So in case of writing to a clean array, head > movement always takes place - > first got to bitmap area, and second to the actual > data area. > > That "written at intervals" is about clearing the > bitmaps after some idle > time. > > In other words, dirtying bitmap bits occurs right > before actual write, > and clearing bits occurs at intervals. > > Sure, if you write to (or near) the same place again > and again, without > giving a chance to md subsystem to actually clean > the bitmap, there will > be no additional head movement. And that means, for > example, tar -xjf > sometimes, since filesystem will place the files > being extracted close to > each other, thus hitting the same bit in the bitmap, > hence md will skip > repeated bitmap updates in this case. > > /mjt > I assume that if a block is already dirty then that is cached somewhere in memory so you aren't writing to the bitmap unless you're changing it for clean to dirty? If that's the case then I would think that writing to the map wouldn't be that expensive? Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
More nVidia 4gb ram problems
Running FC6. When I try to format a Raid 1 device the server locks up when it creates the journal. However if I use just 2 gigs of ram then it doesn't lock up. Asus motherboard. Please CC me as I'm not a list member. Linux version 2.6.19-1.2911.6.5.fc6 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Sun Mar 4 16:05:34 EST 2007 Command line: ro root=LABEL=/ vga=1 pci=nommconf iommu=soft BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e5000 - 0010 (reserved) BIOS-e820: 0010 - abfc (usable) BIOS-e820: abfc - abfce000 (ACPI data) BIOS-e820: abfce000 - abff (ACPI NVS) BIOS-e820: abff - ac00 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fef0 (reserved) BIOS-e820: ff78 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 704448) 1 entries of 3200 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v002 ACPIAM ) @ 0x000fb870 ACPI: XSDT (v001 A M I OEMXSDT 0x04000619 MSFT 0x0097) @ 0xabfc0100 ACPI: FADT (v003 A M I OEMFACP 0x04000619 MSFT 0x0097) @ 0xabfc0290 ACPI: MADT (v001 A M I OEMAPIC 0x04000619 MSFT 0x0097) @ 0xabfc0390 ACPI: MCFG (v001 A M I OEMMCFG 0x04000619 MSFT 0x0097) @ 0xabfc0400 ACPI: OEMB (v001 A M I AMI_OEM 0x04000619 MSFT 0x0097) @ 0xabfce040 ACPI: DSDT (v001 A0368 A0368001 0x0001 INTL 0x02002026) @ 0x Scanning NUMA topology in Northbridge 24 Number of nodes 1 Node 0 MemBase Limit abfc Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 704448) 1 entries of 3200 used NUMA: Using 63 for the hash shift. Using node hash shift of 63 Bootmem setup node 0 -abfc Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 704448 On node 0 totalpages: 704351 DMA zone: 64 pages used for memmap DMA zone: 1449 pages reserved DMA zone: 2486 pages, LIFO batch:0 DMA32 zone: 10943 pages used for memmap DMA32 zone: 689409 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x508 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to physical flat Using ACPI (MADT) for SMP configuration information Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000e5000 Nosave address range: 000e5000 - 0010 Allocating PCI resources starting at b000 (gap: ac00:52c0) SMP: Allowing 2 CPUs, 0 hotplug CPUs PERCPU: Allocating 43264 bytes of per cpu data Built 1 zonelists. Total pages: 691895 Kernel command line: ro root=LABEL=/ vga=1 pci=nommconf iommu=soft Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour VGA+ 80x50 Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Checking aperture... CPU 0: aperture @ 0 size 32 MB No AGP bridge found PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Placing software IO TLB between 0x428f000 - 0x828f000 Memory: 2692344k/2817792k available (2469k kernel code, 125060k reserved, 1938k data, 312k init) Calibrating delay using timer specific routine.. 4824.85 BogoMIPS (lpj=2412427) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 0/0 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 SMP alternatives: switching to UP code ACPI: Core revision 20060707 Using local
Networking Question [ot]
This may be a little off topic but I know there's people here that can give me a quick answer. I'm running Fedora Core 6 and I have two blocks of IP addresses on eth0. 69.50.231.0/28 69.50.231.128/26 Do I need to set some kind of static route so that IPs in one set can talk to the other? If so - how do I do that? Thanks in advance. Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q http://answers.yahoo.com/dir/?link=list=396545367 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Networking Question [ot]
This may be a little off topic but I know there's people here that can give me a quick answer. I'm running Fedora Core 6 and I have two blocks of IP addresses on eth0. 69.50.231.0/28 69.50.231.128/26 Do I need to set some kind of static route so that IPs in one set can talk to the other? If so - how do I do that? Thanks in advance. Food fight? Enjoy some healthy debate in the Yahoo! Answers Food Drink QA. http://answers.yahoo.com/dir/?link=listsid=396545367 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
More nVidia 4gb ram problems
Running FC6. When I try to format a Raid 1 device the server locks up when it creates the journal. However if I use just 2 gigs of ram then it doesn't lock up. Asus motherboard. Please CC me as I'm not a list member. Linux version 2.6.19-1.2911.6.5.fc6 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Sun Mar 4 16:05:34 EST 2007 Command line: ro root=LABEL=/ vga=1 pci=nommconf iommu=soft BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e5000 - 0010 (reserved) BIOS-e820: 0010 - abfc (usable) BIOS-e820: abfc - abfce000 (ACPI data) BIOS-e820: abfce000 - abff (ACPI NVS) BIOS-e820: abff - ac00 (reserved) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fef0 (reserved) BIOS-e820: ff78 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 704448) 1 entries of 3200 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v002 ACPIAM ) @ 0x000fb870 ACPI: XSDT (v001 A M I OEMXSDT 0x04000619 MSFT 0x0097) @ 0xabfc0100 ACPI: FADT (v003 A M I OEMFACP 0x04000619 MSFT 0x0097) @ 0xabfc0290 ACPI: MADT (v001 A M I OEMAPIC 0x04000619 MSFT 0x0097) @ 0xabfc0390 ACPI: MCFG (v001 A M I OEMMCFG 0x04000619 MSFT 0x0097) @ 0xabfc0400 ACPI: OEMB (v001 A M I AMI_OEM 0x04000619 MSFT 0x0097) @ 0xabfce040 ACPI: DSDT (v001 A0368 A0368001 0x0001 INTL 0x02002026) @ 0x Scanning NUMA topology in Northbridge 24 Number of nodes 1 Node 0 MemBase Limit abfc Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 704448) 1 entries of 3200 used NUMA: Using 63 for the hash shift. Using node hash shift of 63 Bootmem setup node 0 -abfc Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 704448 On node 0 totalpages: 704351 DMA zone: 64 pages used for memmap DMA zone: 1449 pages reserved DMA zone: 2486 pages, LIFO batch:0 DMA32 zone: 10943 pages used for memmap DMA32 zone: 689409 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x508 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: BIOS IRQ0 pin2 override ignored. ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to physical flat Using ACPI (MADT) for SMP configuration information Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000e5000 Nosave address range: 000e5000 - 0010 Allocating PCI resources starting at b000 (gap: ac00:52c0) SMP: Allowing 2 CPUs, 0 hotplug CPUs PERCPU: Allocating 43264 bytes of per cpu data Built 1 zonelists. Total pages: 691895 Kernel command line: ro root=LABEL=/ vga=1 pci=nommconf iommu=soft Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour VGA+ 80x50 Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) Checking aperture... CPU 0: aperture @ 0 size 32 MB No AGP bridge found PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Placing software IO TLB between 0x428f000 - 0x828f000 Memory: 2692344k/2817792k available (2469k kernel code, 125060k reserved, 1938k data, 312k init) Calibrating delay using timer specific routine.. 4824.85 BogoMIPS (lpj=2412427) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 0/0 - Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 SMP alternatives: switching to UP code ACPI: Core revision 20060707 Using local APIC
Re: Raid 10 Problems?
--- Michael Tokarev [EMAIL PROTECTED] wrote: Jan Engelhardt wrote: [] The other thing is, the bitmap is supposed to be written out at intervals, not at every write, so the extra head movement for bitmap updates should be really low, and not making the tar -xjf process slower by half a minute. Is there a way to tweak the write-bitmap-to-disk interval? Perhaps something in /sys or ye olde /proc. Maybe linux-raid@ knows 8) Hmm. Bitmap is supposed to be written before actual data write, to mark the to-be-written areas of the array as being written, so that those areas can be detected and recovered in case of power failure during actual write. So in case of writing to a clean array, head movement always takes place - first got to bitmap area, and second to the actual data area. That written at intervals is about clearing the bitmaps after some idle time. In other words, dirtying bitmap bits occurs right before actual write, and clearing bits occurs at intervals. Sure, if you write to (or near) the same place again and again, without giving a chance to md subsystem to actually clean the bitmap, there will be no additional head movement. And that means, for example, tar -xjf sometimes, since filesystem will place the files being extracted close to each other, thus hitting the same bit in the bitmap, hence md will skip repeated bitmap updates in this case. /mjt I assume that if a block is already dirty then that is cached somewhere in memory so you aren't writing to the bitmap unless you're changing it for clean to dirty? If that's the case then I would think that writing to the map wouldn't be that expensive? Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. http://farechase.yahoo.com/promo-generic-14795097 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 10 Problems?
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Mar 4 2007 19:37, Marc Perkel wrote: > >> > >> -b internal -- seems like a good idea to speed > up > >> resynchronization. > > > >I'm trying to figure out what the default is. > > -b none, meaning the whole drive will be > resynchronized when the > even counters don't match. > > http://gentoo-wiki.com/HOWTO_Install_on_Software_RAID#Write-intent_bitmap > > That information has been extremely useful. Thanks a lot. I fund a command to do the bitmap internal after the array was made so I added that. Seems like some of these features should be default. Maybe it's time for the raid folks to update what is default? 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 10 Problems?
--- Jan Engelhardt [EMAIL PROTECTED] wrote: On Mar 4 2007 19:37, Marc Perkel wrote: -b internal -- seems like a good idea to speed up resynchronization. I'm trying to figure out what the default is. -b none, meaning the whole drive will be resynchronized when the even counters don't match. http://gentoo-wiki.com/HOWTO_Install_on_Software_RAID#Write-intent_bitmap That information has been extremely useful. Thanks a lot. I fund a command to do the bitmap internal after the array was made so I added that. Seems like some of these features should be default. Maybe it's time for the raid folks to update what is default? 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 10 Problems?
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Mar 4 2007 19:17, Marc Perkel wrote: > >Thanks - because of your suggestion I had found the > >instructions. But you have some interesting options > >set. > > > >-N nicearray -b internal -e 1.0 > > > >Are these important? > > -N? What's in a name? I suppose, it's not so > important. > (Arrays are identified by their UUID anyway. But > maybe > udev can do something with the name someday as it > does > today with /dev/disk/*.) Not worth starting over for. > > -b internal -- seems like a good idea to speed up > resynchronization. I'm trying to figure out what the default is. > > -e 1.0 -- I wonder why the new superblock format > is > not default in mdadm (0.90 is still used). > Looks interesting for big arrays but not sure it's worth starting over for. Trying to get through a 2 hour sync using 4 500gb sata 2 drives. > > >pci=nommconf iommu=soft > > The nvidia chipset corruption problem? > Yep - that's the one. It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 10 Problems?
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Mar 4 2007 15:10, Marc Perkel wrote: > >> On Mar 4 2007 08:25, Marc Perkel wrote: > >> >I'm running the latest OpenVZ kernel 2.6.18. I'm > >> not > >> >sure if this is a factor or not as the problem > >> occurs > >> >without starting any VEs. > >> > > >> >I've never used raid 10 before (stripes on top > of 2 > >> >mirrors) so I don't have anything to compare > this > >> >with. I'm just wondering if I'm doing something > >> wrong. > >> > >> Are you using raid1+0 (3 md devices) or raid10 (1 > >> raid device)? > >> Depending on which, you might want to try the > other. > > > > > >I'm using 3 devices. Can you use just one? If so - > >how? > >How do I create a raid 10 using mdadm? > > mdadm -C /dev/md0 -N nicearray -b internal -e 1.0 -l > 10 -n 4 /dev/sd[abcd]1 > > for example. (See the manpage for details.) > Thanks - because of your suggestion I had found the instructions. But you have some interesting options set. -N nicearray -b internal -e 1.0 Are these important? I can restart the process. I think that I found my original problem. I forgot to use: pci=nommconf iommu=soft We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 10 Problems?
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Mar 4 2007 08:25, Marc Perkel wrote: > >I'm running the latest OpenVZ kernel 2.6.18. I'm > not > >sure if this is a factor or not as the problem > occurs > >without starting any VEs. > > > >I've never used raid 10 before (stripes on top of 2 > >mirrors) so I don't have anything to compare this > >with. I'm just wondering if I'm doing something > wrong. > > Are you using raid1+0 (3 md devices) or raid10 (1 > raid device)? > Depending on which, you might want to try the other. > > > Jan > -- I'm using 3 devices. Can you use just one? If so - how? How do I create a raid 10 using mdadm? Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Raid 10 Problems?
Running into a problem and not sure what I'm doing wrong. Created a software raid 10 array. Everything seems to be normal except that if you take the array down and run e2fsck on it there are always errors, mostly all little stuff and it recovers without losing any data. I'm running the latest OpenVZ kernel 2.6.18. I'm not sure if this is a factor or not as the problem occurs without starting any VEs. The problem will happen most all the time. I can format the partition, put the data on it then shut it down and run 2efsck and there will be some errors to fix. In the past after running for weeks the raid array will unexpectedly go inti read only mode due to the errors. After running e2fsck it will run normal again. I've never used raid 10 before (stripes on top of 2 mirrors) so I don't have anything to compare this with. I'm just wondering if I'm doing something wrong. I am using ACL and dir_index attributes. If I run e2fsck twice in a row it comes up with no errors he second time. However if I mount the /dev/md2 device and then immediately umount it and run e2fsck again I get some errors. Here's a run I did just mounting and unmounting immediately. e2fsck 1.39 (29-May-2006) Pass 1: Checking inodes, blocks, and sizes Inode 17172774, i_blocks is 8304, should be 19272. Fix? yes Inode 37126149, i_blocks is 872, should be 2192. Fix? yes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: +(39500534--39501904) +(74267806--74267970) Fix? yes Free blocks count wrong for group #1205 (1371, counted=0). Fix? yes Free blocks count wrong for group #2266 (17206, counted=17041). Fix? yes Free blocks count wrong (218321825, counted=218320289). Fix? yes /vz: * FILE SYSTEM WAS MODIFIED * 125791 inodes used (0.11%) 451 non-contiguous inodes (0.4%) # of inodes with ind/dind/tind blocks: 7086/648/0 15831007 blocks used (6.76%) 0 bad blocks 3 large files 107783 regular files 11529 directories 1584 character device files 10 block device files 3 fifos 1 link 4872 symbolic links (4864 fast symbolic links) 1 socket 125783 files Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Raid 10 Problems?
Running into a problem and not sure what I'm doing wrong. Created a software raid 10 array. Everything seems to be normal except that if you take the array down and run e2fsck on it there are always errors, mostly all little stuff and it recovers without losing any data. I'm running the latest OpenVZ kernel 2.6.18. I'm not sure if this is a factor or not as the problem occurs without starting any VEs. The problem will happen most all the time. I can format the partition, put the data on it then shut it down and run 2efsck and there will be some errors to fix. In the past after running for weeks the raid array will unexpectedly go inti read only mode due to the errors. After running e2fsck it will run normal again. I've never used raid 10 before (stripes on top of 2 mirrors) so I don't have anything to compare this with. I'm just wondering if I'm doing something wrong. I am using ACL and dir_index attributes. If I run e2fsck twice in a row it comes up with no errors he second time. However if I mount the /dev/md2 device and then immediately umount it and run e2fsck again I get some errors. Here's a run I did just mounting and unmounting immediately. e2fsck 1.39 (29-May-2006) Pass 1: Checking inodes, blocks, and sizes Inode 17172774, i_blocks is 8304, should be 19272. Fix? yes Inode 37126149, i_blocks is 872, should be 2192. Fix? yes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: +(39500534--39501904) +(74267806--74267970) Fix? yes Free blocks count wrong for group #1205 (1371, counted=0). Fix? yes Free blocks count wrong for group #2266 (17206, counted=17041). Fix? yes Free blocks count wrong (218321825, counted=218320289). Fix? yes /vz: * FILE SYSTEM WAS MODIFIED * 125791 inodes used (0.11%) 451 non-contiguous inodes (0.4%) # of inodes with ind/dind/tind blocks: 7086/648/0 15831007 blocks used (6.76%) 0 bad blocks 3 large files 107783 regular files 11529 directories 1584 character device files 10 block device files 3 fifos 1 link 4872 symbolic links (4864 fast symbolic links) 1 socket 125783 files Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Raid 10 Problems?
--- Jan Engelhardt [EMAIL PROTECTED] wrote: On Mar 4 2007 08:25, Marc Perkel wrote: I'm running the latest OpenVZ kernel 2.6.18. I'm not sure if this is a factor or not as the problem occurs without starting any VEs. I've never used raid 10 before (stripes on top of 2 mirrors) so I don't have anything to compare this with. I'm just wondering if I'm doing something wrong. Are you using raid1+0 (3 md devices) or raid10 (1 raid device)? Depending on which, you might want to try the other. Jan -- I'm using 3 devices. Can you use just one? If so - how? How do I create a raid 10 using mdadm? Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
