Re: quota deadlock in 2.4.5-pre4
Alexander Viro wrote: > > > Stop here. You have a hole in quota file. You are not supposed to. I think it's a misfit between Linus' kernel and the quota tools from http://sourceforge.net/projects/linuxquota/ Running `quotacheck' creates an aquota.user which is only ~7200 bytes in size. But the quota code in Linus' kernel tries to write quota info into this file at offset inode->i_uid * sizeof(struct dqblk) So Linus' quotafile is just a flat array. With my UID of 34202, ->i_size grew to over a meg. It's super-holey. Now I *assume* that quotacheck should have instantiated the block which corresponds to 34202 in aquota.user. And when new users are added to the quotafile, the quota tools must instantiate the user's corresponding blocks, so filesystems aren't nastily reentered in this manner. Sounds good to me, anyway. But quotacheck didn't instantiate my block. Linus' tree and Alan's are showing a 2000 line diff in dquot.c alone. `quotaon' seems to be passing arguments into sys_quotactl() which it doesn't understand, etc. So. I'd prefer to not do further ext3 quota testing until Linus gets an update. Alan, is it possible to push this along a bit? - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Wed, 23 May 2001, Edgar Toernig wrote: > And with special "ctrl" devices (ie /dev/ttyS0 and /dev/ttyS0ctrl): > This _may_ work for some kind of devices. But serial ports are one > example where it simply will _not_. It requires that you know the That's quite funny, you know... From: Dennis Ritchie ([EMAIL PROTECTED]) Subject: Re: Plan 9 (was Re: Rubouts) Newsgroups: alt.folklore.computers Date: 1998/10/12 Neil Franklin wrote: > > No ioctl()s? > > Something like:echo "38400,8,n,1" > /ioctrl/ttyS0? > > Now that would be cool. > Exactly like that, though it would be /dev/eia80ctl . No ioctl(). > Is there anyone who has an URL about Plan 9. Code download? > http://plan9.bell-labs.com/plan9 Dennis - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Daniel Phillips wrote: > > On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote: > > On Mon, 21 May 2001, Daniel Phillips wrote: > > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote: > > > > What I'd like to see: > > > > > > > > - An interface for registering an array of related devices > > > > (almost always two: raw and ctl) and their legacy device numbers > > > > with a single userspace callout that does whatever /dev/ creation > > > > needs to be done. Thus, naming and permissions live in user > > > > space. No "device node is also a directory" weirdness... > > > > > > Could you be specific about what is weird about it? > > > > *boggle* > > > >[general sense of unease] I fully agree with Oliver. It's an abomination. > > I don't think it's likely to be even workable. Just consider the > > directory entry for a moment - is it going to be marked d or [cb]? > > It's going to be marked 'd', it's a directory, not a file. Aha. So you lose the S_ISCHR/BLK attribute. > > If it doesn't have the directory bit set, Midnight commander won't > > let me look at it, and I wouldn't blame cd or ls for complaining. If it > > does have the 'd' bit set, I wouldn't blame cp, tar, find, or a > > million other programs if they did the wrong thing. They've had 30 > > years to expect that files aren't directories. They're going to act > > weird. > > No problem, it's a directory. Directories are not allowed to be read from/written to. The VFS may support it, but it's not (current) UNIX. > > Linus has been kicking this idea around for a couple years now and > > it's still a cute solution looking for a problem. It just doesn't > > belong in UNIX. > > Hmm, ok, do we still have any *technical* reasons? So with your definition, I have a fs-object that is marked as a directory but opening it opens a device. Pretty nice. How I'm supposed to list it's contents? open+readdir? But the open has nasty side effects. So you have a directory that you are not allowed to list (because of the possible side effects) but is allowed to be read from/written to maybe even issue ioctls to?. And you call that sane??? IMO the whole idea of arguments following the device name is junk (incl a "/ctrl"). Just think about the implications of the original "/dev/ttyS0/19200" suggestion. It sounds nice and tempting. But which programs will benefit. Which gets confused. What will be cleaned up. After some thoughts you'll find out that it's useless ;-) And with special "ctrl" devices (ie /dev/ttyS0 and /dev/ttyS0ctrl): This _may_ work for some kind of devices. But serial ports are one example where it simply will _not_. It requires that you know the name of the device. For ttys this is often not the case. Even if you manage to get some name for stdin for example - now I should simply attach a "ctrl" to that name to get a control channel??? At least dangerous. If I'm lucky I only get an EPERM... Ciao, ET. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
Linus Torvalds writes: > The problem is that if you expect to get nice code, you have to have nice > interfaces and infratructure. And ioctl's aren't it. ... > But that absolutely _requires_ that the driver writers should never see > the silly "pass a random number and a random argument type" kind of > interface with no structure or infrastructure in place. > > Because right now even _good_ programmers make a mess of the fact that > they get passed a bad interface. > > Think of it this way: the user interface to opening a file is > "open()" with pathnames and magic flags. But a filesystem never even > _sees_ that interface, it sees a very nicely structured setup where all > the argument parsing and locking has already been done for it, and the > magic flags don't even exist any more as far as the low-level FS is > concerned. Which is why filesystems _can_ be clean. > > In contrast, ioctl's are passed through directly, with no help to make > them clean. You want a well-defined interface, allowing over-network use? Well, here you go, the CORBA ORB patch for Linux 2.4 kernels: http://korbit.sourceforge.net/ Do you want that against 2.4.5-pre5 or what? Plain ASCII email? :-) The really sick thing is that I could actually use this too. It handles the DSP problem well. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: ECN is on!
Richard Gooch <[EMAIL PROTECTED]> writes: > Sure, Dave is being bloody-minded, but that's the only way we'll see > people get off their fat, lazy asses and fix their broken systems. > In fact, hopefully he's still in a dark mood, and he may take up the > suggestion to bounce mails of the following type: > - MIME encoded > - HTML encoded > - quoted printables (those stupid "=20" things are particuarly hard to > read). MIME is no encoding, but a way to declare mail contents and encode binary data. You need not use it on mail you send. HTML is no encoding. (No doubt it's usually sent by people without A Clue[tm] or being ruthless.) quoted-printable is an encoding, and it's probably around for ten years now. I can send base64 if you like that better, but then, even more people will cry, while others don't even notice. Gnus 5.8 + Emacs, mutt, Netscape Communicator are three packages which deal with MIME-"enhanced" mail. Plus, people which use any characters beyond ASCII have no real choice but to use MIME; if they have MTAs in between that don't talk ESMTP/8BITMIME, then quoted-printable is what happens. Use emil, metamail or such if you want to keep your mailer. -- Matthias Andree - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Andreas, I think that the issue is something different. Suppose the snapshot has been created. I know that this can be done safely with the API's you allude to. Life goes on and the journal FS keeps changing the file system and if the system doesn't crash, everything is fine: blocks get copied correctly from the primary volume to the snapshot volume. Now consider a crash -- not during snapshot creation, but way after that when "life is going on". Suppose there is a two block transaction that has made it to the journal and after writing one block to the fs location the system crashes. The journal replay will try to write that block again. But during recovery, LVM cannot possibly know if the whole process of copying out the data from the current to the snapshot area completed during the previous run. Yes, LVM updates the redirection table first and then copies, but, still, you don't know _where exactly_ the writes stopped happening and in particular you don't know if the block was copied already or not. So during replay it is quite possible that LVM corrupts the snapshot. It's better to keep the snapshot in the old volume and write the new data to a separate area (that's what most commercial systems do I think). It avoid redirections and copying upon write. When you delete the snapshot you have to copy, but you can do that as a low priority process. Finally, as you pointed out a full volume is handled better too in that way, since you don't terminate the snapshot but you tell the current volume that it is full. Hmm, I was expecting a storm of email explaining what I have misunderstood, but it has in fact been rather quiet... - Peter - On Tue, 22 May 2001, Andreas Dilger wrote: > Peter Braam writes: > > On Tue, 22 May 2001, Andreas Dilger wrote: > > > Actually, the LVM snapshot > > > interface has (optional) hooks into the filesystem to ensure that it > > > is consistent at the time the snapshot is created. > > > > File system journal recovery can corrupt a snapshot, because it copies > > data that needs to be preserved in a snapshot. During journal replay such > > data may be copied again, but the source can have new data already. > > The way it is implemented in reiserfs is to wait for existing transactions > to complete, entirely flush the journal and block all new transactions from > starting. Stephen implemented a journal flush API to do this for ext3, but > the hooks to call it from LVM are not in place yet. This way the journal is > totally empty at the time the snapshot is done, so the read-only copy does > not need to do journal recovery, so no problems can arise. > > Cheers, Andreas > -- - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Tuesday 22 May 2001 19:49, Oliver Xymoron wrote: > On Tue, 22 May 2001, Daniel Phillips wrote: > > > I don't think it's likely to be even workable. Just consider the > > > directory entry for a moment - is it going to be marked d or > > > [cb]? > > > > It's going to be marked 'd', it's a directory, not a file. > > Are we talking about the same proposal? The one where I can open > /dev/dsp and /dev/dsp/ctl? But I can still do 'cat /dev/hda > > /dev/dsp'? We already support read/write on directories in the VFS, that's not a problem. > It's still a file. If it's not a file anymore, it ain't UNIX. It's a file with the directory bit set, I believe that's UNIX. > > > If it doesn't have the directory bit set, Midnight commander > > > won't let me look at it, and I wouldn't blame cd or ls for > > > complaining. If it does have the 'd' bit set, I wouldn't blame > > > cp, tar, find, or a million other programs if they did the wrong > > > thing. They've had 30 years to expect that files aren't > > > directories. They're going to act weird. > > > > No problem, it's a directory. > > > > > Linus has been kicking this idea around for a couple years now > > > and it's still a cute solution looking for a problem. It just > > > doesn't belong in UNIX. > > > > Hmm, ok, do we still have any *technical* reasons? > > If you define *technical* to not include design, sure. Sorry, I don't see what you mean, do you mean the design is difficult? > Oh, did I mention unnecessary, solvable in userspace? That's exactly the point: the generic filesystem allows all the funny-shaped stuff to be dealt with in user space. The filesystem itself is lovely and clean. BTW, I didn't realize I was reinventing Linus's wheel, this just seemed very obvious and natural to me. So I had to believe there's a technical obstacle somewhere. Has anyone written code to demonstrate the idea? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Tue, 22 May 2001, Linus Torvalds wrote: > > On Tue, 22 May 2001, Andreas Dilger wrote: Actually, the LVM snapshot > interface has (optional) hooks into the filesystem to ensure that it > is consistent at the time the snapshot is created. But I think that LVM is implemented "the wrong way around". File system journal recovery can corrupt a snapshot, because it copies data that needs to be preserved in a snapshot. During journal replay such data may be copied again, but the source can have new data already. Most LVM snapshot systems write the new data in the separate volume and don't copy the old data that eliminates this problem (and also eliminates the copy of data but introduces data copy when a snapshot is removed). - Peter - - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Tue, 22 May 2001, Andreas Dilger wrote: > > Actually, the LVM snapshot interface has (optional) hooks into the filesystem > to ensure that it is consistent at the time the snapshot is created. Note that this is still fundamentally a broken interface: the filesystem may not _have_ a block device underneath it, yet you might very well like to do defragmentation and backup none-the-less. Also, lvm snapshots are fundamentally limited to read-only data, which means that the LVM interfaces cannot be used for defragmentation and lazy fsck etc anyway. You _have_ to do those at a filesystem level. disk snapshots are useful, but they are not the answer. Linus - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
>> What is the communication between user space and kernel >> that transports device identities? > It doesn't change, the same symbolic names still work. But today, unless you think of devfs or so, device identities are not transported by symbolic names. They are given by device numbers. [Yes, symbolic names have a certain secondary role, e.g. in error messages, or perhaps to indicate the boot device.] Andries - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: ECN is on!
On Tuesday 22 May 2001 12:14, David S. Miller wrote: > Matti Aarnio writes: > > I am contemplating to periodically turn off the ECN bit to > > let email out, but DaveM has veto there. > > I veto, the whole point of moving to ECN was to make a statement and > get people to fix their kit. > > We will remove these people, that's all. > How about telling _ALL_ the lists in good time then - not just one or two. All recent items (last 6 months) from Dave Miller to Linux-Hams below... Re: ECN is on! Date: Tue, 22 May 2001 04:14:54 -0700 (PDT) From: "David S. Miller" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Re: Welcome to linux-hams Date: Sun, 10 Sep 2000 18:37:55 -0700 From: "David S. Miller" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Re: All messages double in Linux-Hams Date: Fri, 8 Sep 2000 18:13:15 -0700 From: "David S. Miller" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] -- Robin - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)
On Tue, 22 May 2001, Daniel Phillips wrote: > > I don't think it's likely to be even workable. Just consider the > > directory entry for a moment - is it going to be marked d or [cb]? > > It's going to be marked 'd', it's a directory, not a file. Are we talking about the same proposal? The one where I can open /dev/dsp and /dev/dsp/ctl? But I can still do 'cat /dev/hda > /dev/dsp'? It's still a file. If it's not a file anymore, it ain't UNIX. > > If it doesn't have the directory bit set, Midnight commander won't > > let me look at it, and I wouldn't blame cd or ls for complaining. If it > > does have the 'd' bit set, I wouldn't blame cp, tar, find, or a > > million other programs if they did the wrong thing. They've had 30 > > years to expect that files aren't directories. They're going to act > > weird. > > No problem, it's a directory. > > > Linus has been kicking this idea around for a couple years now and > > it's still a cute solution looking for a problem. It just doesn't > > belong in UNIX. > > Hmm, ok, do we still have any *technical* reasons? If you define *technical* to not include design, sure. Oh, did I mention unnecessary, solvable in userspace? -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Tuesday 22 May 2001 17:24, Oliver Xymoron wrote: > On Mon, 21 May 2001, Daniel Phillips wrote: > > On Monday 21 May 2001 19:16, Oliver Xymoron wrote: > > > What I'd like to see: > > > > > > - An interface for registering an array of related devices > > > (almost always two: raw and ctl) and their legacy device numbers > > > with a single userspace callout that does whatever /dev/ creation > > > needs to be done. Thus, naming and permissions live in user > > > space. No "device node is also a directory" weirdness... > > > > Could you be specific about what is weird about it? > > *boggle* > >[general sense of unease] > > I don't think it's likely to be even workable. Just consider the > directory entry for a moment - is it going to be marked d or [cb]? It's going to be marked 'd', it's a directory, not a file. > If it doesn't have the directory bit set, Midnight commander won't > let me look at it, and I wouldn't blame cd or ls for complaining. If it > does have the 'd' bit set, I wouldn't blame cp, tar, find, or a > million other programs if they did the wrong thing. They've had 30 > years to expect that files aren't directories. They're going to act > weird. No problem, it's a directory. > Linus has been kicking this idea around for a couple years now and > it's still a cute solution looking for a problem. It just doesn't > belong in UNIX. Hmm, ok, do we still have any *technical* reasons? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: ECN is on!
FOLKS, I HAVE ALL THE TIME USED 'Reply-To:' HEADER POINTING TO linux-kernel -- INSTEAD OF ALL THE LISTS... If you want to continue this, do it there. (Before I decide to taboo "Re: ECN is on!" subject line..) On Tue, May 22, 2001 at 12:23:29PM -0400, Richard Gooch wrote: ... > Well, while that would be somewhat satisfying, there is a problem if > the message gets corrupted by this. And since some people send to the > list without being subscribed (or, like me, have duplicate filtering), > they'll never see that their message was mangled as it passed through > the list. > > Nope, a bounce is better. If you're going to do these things, feedback > is essential. The bounce isn't meant to offend the sender, it's > designed to let them know what's happening. The only GOOD time to bounce is at SMTP reception into VGER, not latter. It doesn't have facilities to do all what Majordomo taboo filters do now. (Just because I have been lazy and haven't done any such content filters for vger.) With ECN on, emailed bounce messages won't (necessarily) make it to the sender at all. Majordomo's filter bounces the message to be approved by list owner -- who usually uses the 'D' key to my knowledge. > Regards, > > Richard > Permanent: [EMAIL PROTECTED] > Current: [EMAIL PROTECTED] /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
RE: ECN is on!
Not to mention, not everyone on the list runs their own mailservers. -Original Message- From: Steve Modica [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 22, 2001 12:28 To: Rogier Wolff Cc: Richard Gooch; Brent D. Norris; David S. Miller; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: ECN is on! Rogier Wolff wrote: > The "we'll turn it on in February" warning is worth NOTHING in this > situation: February comes and goes. March comes and goes. Everybody > who read the warning will think: Ok, so I must be fine. > > A warning of the form: "ECN will go on as soon as this message clears > the queues" would've been useful, as thousands (hundreds?) suddenly get > nothing anymore. > I agree with this line of thinking. The various academics studying geology have been warning California about "The Big One" for years now, and no one seems to care anymore. I don't think anyone's being lazy and I certainly don't have the information to comment on the size of their butts. So I'd rather just assume they were working very hard on other things (like getting TPC-H benchmarks to run!) Steve -- Steve Modica Manager - Networking Drivers Group "Give a man a fish, and he will eat for a day, hit him with a fish and he leaves you alone" - me - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Tue, 22 May 2001, Jan Harkes wrote: > > something like, > > ssize_t kioctl(int fd, int type, int cmd, void *inbuf, size_t inlen, > void *outbuf, size_t outlen); > > As far as functionality and errors it works like read/write in a single > call, pretty much what Richard proposed earlier with a new 'transaction' > syscall. Maybe type is not needed, and cmd can be part of the inbuf in > which case it would be identical. I'd rather have type and cmd there, simply because right now the "cmd" passed in to the ioctl is not well-defined, as several different drivers use the same numbers for different things (which is why I want to expand that to to get uniqueness). Also, I think the cmd is separate from the data, so I don't think it necessarily makes sense to mix the two. Even if we want to have an ASCII command, I'd think that should be separate from the arguments, ie we'd have ssize_t kioctl(int fd, const char *cmd, const void *inbuf ... instead of trying to mix them. This is especially true as the "inbuf" would be a user-mode pointer, while "cmd" would come from kernel space (whether in the form of a number pair or as a kernel string). Linus - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: ECN is on!
Rogier Wolff wrote: > The "we'll turn it on in February" warning is worth NOTHING in this > situation: February comes and goes. March comes and goes. Everybody > who read the warning will think: Ok, so I must be fine. > > A warning of the form: "ECN will go on as soon as this message clears > the queues" would've been useful, as thousands (hundreds?) suddenly get > nothing anymore. > I agree with this line of thinking. The various academics studying geology have been warning California about "The Big One" for years now, and no one seems to care anymore. I don't think anyone's being lazy and I certainly don't have the information to comment on the size of their butts. So I'd rather just assume they were working very hard on other things (like getting TPC-H benchmarks to run!) Steve -- Steve Modica Manager - Networking Drivers Group "Give a man a fish, and he will eat for a day, hit him with a fish and he leaves you alone" - me - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: ECN is on!
Richard Gooch wrote: > Dave sent a message out a week or two ago saying he was going to do it > soon. And back in January he said he'd be doing it in February. The > kernel list FAQ has stated this right at the top, in big, bright red > letters. Yesterday, after I saw Dave's announcement, I updated the FAQ > to reflect that we're now running ECN. > > People have had plenty of warning. Think of it as a bonus that it > didn't happen back in February. They've had an extra 3 months to sort > something out. The "we'll turn it on in February" warning is worth NOTHING in this situation: February comes and goes. March comes and goes. Everybody who read the warning will think: Ok, so I must be fine. A warning of the form: "ECN will go on as soon as this message clears the queues" would've been useful, as thousands (hundreds?) suddenly get nothing anymore. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: ECN is on!
Richard Gooch wrote: > In fact, hopefully he's still in a dark mood, and he may take up the > suggestion to bounce mails of the following type: > - MIME encoded > - HTML encoded > - quoted printables (those stupid "=20" things are particuarly hard to > read). Surely it'd be better to get the list to filter them through stripmime? I'd be tempted to put a message at the top at the same time: "*WARNING* The message below was sent by someone too clueless to configure their email client properly" :-) Tony -- "Two weeks before due date, the programmers work 22 hour days cobbling an application from... (apparently) one programmer bashing his face into the keyboard." -- Dilbert [EMAIL PROTECTED] http://www.nothing-on.tv - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partio
[trimmed cc list down a bit - my MUA does not allow for so long CC:] On 22 May 01 at 9:33, Jan Harkes wrote: > > something like, > > ssize_t kioctl(int fd, int type, int cmd, void *inbuf, size_t inlen, >void *outbuf, size_t outlen); If we are inventing new API, then if we could have ssize_t kioctl(int fd, int type, int cmd, const struct iovec* riov, size_t riov_len, const struct iovec* wiov, size_t wiov_len); then I'm almost sure that it will save couple of passing pointer to pointer in structure headaches - for sure it will in code I maintain (ncpfs). Best regards, Petr Vandrovec [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: ECN is on!
Brent D. Norris writes: > > I veto, the whole point of moving to ECN was to make a statement and > > get people to fix their kit. > > > > We will remove these people, that's all. > > Isn't this a problem though because the messge saying that ECN was > enabled was set after ECN was enabled? Thus these people have no > idea what is going on and they probably won't know what to fix until > they do. Dave sent a message out a week or two ago saying he was going to do it soon. And back in January he said he'd be doing it in February. The kernel list FAQ has stated this right at the top, in big, bright red letters. Yesterday, after I saw Dave's announcement, I updated the FAQ to reflect that we're now running ECN. People have had plenty of warning. Think of it as a bonus that it didn't happen back in February. They've had an extra 3 months to sort something out. I note with disgust the number of places which should know better, but still haven't fixed their kit. Most appalling was missionalcriticallinux.com. Shame! Sure, Dave is being bloody-minded, but that's the only way we'll see people get off their fat, lazy asses and fix their broken systems. In fact, hopefully he's still in a dark mood, and he may take up the suggestion to bounce mails of the following type: - MIME encoded - HTML encoded - quoted printables (those stupid "=20" things are particuarly hard to read). Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: ECN is on!
Alan Cox writes: > > Matti Aarnio writes: > > > I am contemplating to periodically turn off the ECN bit to > > > let email out, but DaveM has veto there. > > > > I veto, the whole point of moving to ECN was to make a statement and > > get people to fix their kit. > > > > We will remove these people, that's all. > > Since HTML email also has a spec can we remove the people who moan > about that too ;) I'm sure M$ Exchange has a spec too. Doesn't mean we should support it. As a community, we need to fight against the darkness. > "MIME, oh mime, how I hate thee. Let me stick pins in you to >count the ways..." -- Ben LaHaise Amen, brother! Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Tue, May 22, 2001 at 04:31:37PM +0100, Alan Cox wrote:
> > `the class of devices in question' was cryptographic devices, and possibly
> > other transactional DSPs. I don't consider audio to be transactional.
> > in any case, you can do transactional things with two threads, as long
> > as they each have their own fd on the device. Think of the fd as your
> > transaction handle.
>
> Thats a bit pathetic. So I have to fill my app with expensive pthread locks
> or hack all the drivers and totally change the multi-open sematics in the ABI
huh?
void thread_init(void) {
int fd = open("/dev/crypto");
real_thread_init(fd);
}
where was that lock again?
and notice this idea is only for transactional things -- what
transactional things do sound drivers do?
--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
> `the class of devices in question' was cryptographic devices, and possibly > other transactional DSPs. I don't consider audio to be transactional. > in any case, you can do transactional things with two threads, as long > as they each have their own fd on the device. Think of the fd as your > transaction handle. Thats a bit pathetic. So I have to fill my app with expensive pthread locks or hack all the drivers and totally change the multi-open sematics in the ABI I think I'll stick to ioctl cleaned up - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Tue, May 22, 2001 at 08:49:04AM +0100, Alan Cox wrote: > > For _devices_, though? I don't expect my mouse to work if gpm and xfree > > both try to consume device events from the same filp. Heck, it doesn't > > even work when they try to consume events from the same inode :-) I think > > this is a reasonable restriction for the class of devices in question. > > Not really. Think about basic things like full duplex audio with two threads `the class of devices in question' was cryptographic devices, and possibly other transactional DSPs. I don't consider audio to be transactional. in any case, you can do transactional things with two threads, as long as they each have their own fd on the device. Think of the fd as your transaction handle. -- Revolutions do not require corporate support. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)
On Mon, 21 May 2001, Daniel Phillips wrote: > On Monday 21 May 2001 19:16, Oliver Xymoron wrote: > > What I'd like to see: > > > > - An interface for registering an array of related devices (almost > > always two: raw and ctl) and their legacy device numbers with a > > single userspace callout that does whatever /dev/ creation needs to > > be done. Thus, naming and permissions live in user space. No "device > > node is also a directory" weirdness... > > Could you be specific about what is weird about it? *boggle* Without precedent in any other UNIX? Or other operating systems, for that matter? Can you honestly say it doesn't strike you as weird? It's beating the least surprise rule with a big stick, fercryinoutloud. Ok, so technically UNIX directories were once just files. But it's been a long time since people thought exposing that implementation detail was a good idea, and anyway, it's the opposite situation (and no longer true on modern fses). I don't think it's likely to be even workable. Just consider the directory entry for a moment - is it going to be marked d or [cb]? If it doesn't have the directory bit set, Midnight commander won't let me look at it, and I wouldn't blame cd or ls for complaining. If it does have the 'd' bit set, I wouldn't blame cp, tar, find, or a million other programs if they did the wrong thing. They've had 30 years to expect that files aren't directories. They're going to act weird. Linus has been kicking this idea around for a couple years now and it's still a cute solution looking for a problem. It just doesn't belong in UNIX. More importantly, there's no call for the weirdness. Look, we've already got to have a userspace callout for new devices so that we can do config, firmware downloading, automounting, etc. There's no reason we can't stick the rest of the dynamic /dev/ magic in userspace with the same mechanism. -- "Love the dolphins," she advised him. "Write by W.A.S.T.E.." - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
On Monday 21 May 2001 19:16, Oliver Xymoron wrote: > What I'd like to see: > > - An interface for registering an array of related devices (almost > always two: raw and ctl) and their legacy device numbers with a > single userspace callout that does whatever /dev/ creation needs to > be done. Thus, naming and permissions live in user space. No "device > node is also a directory" weirdness... Could you be specific about what is weird about it? > ...which is overkill in the vast majority of cases. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On Monday 21 May 2001 14:43, [EMAIL PROTECTED] wrote: > How about: > > # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap > # ls /dev/mypartition > basesizedevicetype > > Generally, we shouldn't care which order the kernel enumerates > devices in or which device number gets assigned internally. If > we did need to care, we'd just do: > > # echo 666 >/dev/mypartition/number > > Only a single thing is of interest. > What is the communication between user space and kernel > that transports device identities? It doesn't change, the same symbolic names still work. What's happening in my example is, we've gotten rid of the can't-get-there-from-here device naming heirarchy. It should be clear by now that we can't capture 'physical device location' and 'device function' in one tree. So instead, 'physical device' is a property of 'logical device'. The tree is now optional. > Note that there is user (human) / user space (programs) / kernel. > > This user has interesting machinery in his hands, > but his programs have only strings (path names, fake or not) > to give to the kernel in open() and mount() calls. > > Now the device path is so complicated that the user is unable to > describe it using a path name. devfs made an attempt listing > controller, lun, etc etc but /dev/ide/host0/bus1/target1/lun0/disc is > not very attractive, and things only get worse. Yes, we flatten that by making host, bus, target and lun all properties of /proc/ide/hda. Our mistake up to now is that we've tried to carry the logical view and physical view of the device in one name, or equivalently, in path+name. Let the physical device be a property of the logical device and we no longer have our thumb tied to our nose. > When I go to a bookshop to buy a book, I can do so without specifying > all of Author, Editors, Title, Publisher, Date, ISBN, nr of pages, > ... A few items suffice. Often the Title alone will do. > > We want an interface where the kernel exports what it has to offer > and the user can pick. Yes, that Zip drive - never mind the bus. > But can distinguish - Yes, that USB Zip drive, not the one > on the parallel port. 100% agreed. IOW, when the device *does* move we can usually deduce where it's moved to, so lets update the hda's bus location automatically whenever we can (log a message!) and only bother the user about it if it's ambiguous. For good measure, have a system setting that says 'on a scale of 0 to 5, this is how interested I am in being bothered about the fact that a device seems to have moved'. > The five minute hack would number devices 1, 2, 3 in order of > detection, offer the detection message in > /devices//detectionmessage and a corresponding device node in > /devices//devicenode. The sysadmin figures out what is what, > makes a collection of symlinks with his favorite names, and everybody > is happy. > > Until the next reboot. Or until device removal and addition. > There must be a way to give permanence to an association > between name and device. Symlinks into a virtual filesystem > like /devices are not good enough. Turning the five minute > hack into a ten minute hack we take the md5sum of the part > of the bootmessage that is expected to be the same the next time > we encounter this device and use that as device number. > > I think a system somewhat in this style could be made to work well. Yes, we are advocating the same thing. I didn't mention that the device properties are supposed to be persistent, did I? If you accept the idea of persistent device properties then the obvious thing to do is to match them up against the detected devices. I didn't want to bring up the persistency thing right away because it begs the question of where you store the persistent data for the root device. Until the namespace issue is resolved this is mainly a distraction. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code in userspace
On Monday 21 May 2001 10:14, Lars Marowsky-Bree wrote: > On 2001-05-19T16:25:47, > >Daniel Phillips <[EMAIL PROTECTED]> said: > > How about: > > > > # mkpart /dev/sda /dev/mypartition -o size=1024k,type=swap > > # ls /dev/mypartition > > base sizedevice type > > # cat /dev/mypartition/size > > 1048576 > > # cat /dev/mypartition/device > > /dev/sda > > # mke2fs /dev/mypartition > > Ek. You want to run mke2fs on a _directory_ ? Could you be specific about what is wrong with that? Assuming that this device directory lives on a special purpose filesystem? > If anything, /dev/mypartition/realdev Then every fstab in the world has to change, not to mention adding verbosity to interactive commands. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: ECN is on!
"David S. Miller" wrote: > > Matti Aarnio writes: > > I am contemplating to periodically turn off the ECN bit to > > let email out, but DaveM has veto there. > > I veto, the whole point of moving to ECN was to make a statement and > get people to fix their kit. > > We will remove these people, that's all. > > Later, > David S. Miller > [EMAIL PROTECTED] > - > To unsubscribe from this list: send the line "unsubscribe linux-net" in > the body of a message to [EMAIL PROTECTED] Perhaps it's none of my business, but it doesn't seem very sporting to just turn something on that breaks stuff and say "you had fair warning". Why not shut it back off, issue a statement saying it works now and will be re-enabled on June 10th or something, and everyone must do thus and so or they will break on that day? Vague things like "it'll be turned on real soon now" or ASAP really mean "never" since admins always have things with real deadlines at the top of their list. Steve -- Steve Modica Manager - Networking Drivers Group "Give a man a fish, and he will eat for a day, hit him with a fish and he leaves you alone" - me - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
On Mon, May 21, 2001 at 03:10:32PM -0700, Linus Torvalds wrote: > That, in turn, might be as simple as changing the ioctl incoming arguments > of into a structure like . At least make sure that the 'kioctl' returns the number of bytes placed into the output buffer, as userspace doesn't necessarily know how much data would be returned. Coda's kernel module forwards control data up to userspace and uses a reasonably messy 'pioctl' wrapper (also used by AFS afaik) around an ioctl to inform the kernel module of how much data to copy through. something like, ssize_t kioctl(int fd, int type, int cmd, void *inbuf, size_t inlen, void *outbuf, size_t outlen); As far as functionality and errors it works like read/write in a single call, pretty much what Richard proposed earlier with a new 'transaction' syscall. Maybe type is not needed, and cmd can be part of the inbuf in which case it would be identical. I guess that type is introduced to resolve existing ioctl number collisions. Jan - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: Fix for an SMP locking bug in NFS code
> I've already run this by Trond so I'm sending this patch without > further ado. It adds a lock_kernel around a call into NLM code, > and removes an extraneous (really) lock_kernel in sys_fcntl64. [EMAIL PROTECTED] is the locking code maintainer if he's not already seen this - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Fix for an SMP locking bug in NFS code
Linus,
I've already run this by Trond so I'm sending this patch without
further ado. It adds a lock_kernel around a call into NLM code,
and removes an extraneous (really) lock_kernel in sys_fcntl64.
In more detail:
There's no lock_kernel around the F_SETLK case in fcntl, but
some of the NLM code which gets called in the NFS case needs
to be protected by locks (in particular, nlmclnt_block fiddles
with the global list nlm_blocked). We decided that, to protect
the RPC code as well, the best place to put a lock would be
around the call to nlmclnt_proc in nfs_lock.
There is, on the other hand, a lock_kernel in fcntl64, and
analysis shows that if it's not needed in fcntl - which it
shouldn't be, if the filesystems do any necessary locking -
then it's not needed in fcntl64 either (the code is essentially
identical).
Cheers,
Matt
diff -u --recursive --new-file linux-2.4.5-pre4/fs/fcntl.c
linux-2.4.5-pre4-nfslockfix/fs/fcntl.c
--- linux-2.4.5-pre4/fs/fcntl.c Thu Nov 16 17:50:25 2000
+++ linux-2.4.5-pre4-nfslockfix/fs/fcntl.c Tue May 22 22:37:32 2001
@@ -338,7 +338,6 @@
if (!filp)
goto out;
- lock_kernel();
switch (cmd) {
case F_GETLK64:
err = fcntl_getlk64(fd, (struct flock64 *) arg);
@@ -353,7 +352,6 @@
err = do_fcntl(fd, cmd, arg, filp);
break;
}
- unlock_kernel();
fput(filp);
out:
return err;
diff -u --recursive --new-file linux-2.4.5-pre4/fs/nfs/file.c
linux-2.4.5-pre4-nfslockfix/fs/nfs/file.c
--- linux-2.4.5-pre4/fs/nfs/file.c Tue May 22 22:32:52 2001
+++ linux-2.4.5-pre4-nfslockfix/fs/nfs/file.c Tue May 22 22:36:00 2001
@@ -299,10 +299,13 @@
if (status < 0)
return status;
- if ((status = nlmclnt_proc(inode, cmd, fl)) < 0)
+ lock_kernel();
+ status = nlmclnt_proc(inode, cmd, fl);
+ unlock_kernel();
+ if (status < 0)
return status;
- else
- status = 0;
+
+ status = 0;
/*
* Make sure we clear the cache whenever we try to get the lock.
Re: ECN is on!
On Tue, May 22, 2001 at 06:51:57AM -0500, Brent D. Norris wrote: > > I veto, the whole point of moving to ECN was to make a statement and > > get people to fix their kit. > > > Isn't this a problem though because the messge saying that ECN was enabled > was set after ECN was enabled? Thus these people have no idea what is > going on and they probably won't know what to fix until they do. Not really, Dave Miller warned in advance that vger would enable ECN Real Soon Now [tm]. If that wasn't a trigger for people to test if their stuff could handle ECN, what does? Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: ECN is on!
> I veto, the whole point of moving to ECN was to make a statement and > get people to fix their kit. > Isn't this a problem though because the messge saying that ECN was enabled was set after ECN was enabled? Thus these people have no idea what is going on and they probably won't know what to fix until they do. > We will remove these people, that's all. > > Later, > David S. Miller > [EMAIL PROTECTED] > - > 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/ > Brent Norris Executive Advisor -- WKU-Linux - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: ECN is on!
> Matti Aarnio writes: > > I am contemplating to periodically turn off the ECN bit to > > let email out, but DaveM has veto there. > > I veto, the whole point of moving to ECN was to make a statement and > get people to fix their kit. > > We will remove these people, that's all. Since HTML email also has a spec can we remove the people who moan about that too ;) Alan -- "MIME, oh mime, how I hate thee. Let me stick pins in you to count the ways..." -- Ben LaHaise - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: ECN is on!
Matti Aarnio writes: > I am contemplating to periodically turn off the ECN bit to > let email out, but DaveM has veto there. I veto, the whole point of moving to ECN was to make a statement and get people to fix their kit. We will remove these people, that's all. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
ECN is on!
... and immediately I have been able to verify a bunch of domains/servers which won't get thru when incoming connection has ECN.I tested all of these with Linux running ECN, and Solaris 2.6 without ECN. When Solaris got connection, and ECN-Linux didn't, domain and its server got listed. Amazing share of these troubled destination systems run some firewall which thinks it is cool to fuck SMTP protocol. (I mean obscuring responses given by the remote system, frobbing incoming protocol if some particular detail doesn't please the rules it presumes to play with, etc..) I am contemplating to periodically turn off the ECN bit to let email out, but DaveM has veto there. This list is NOT exhaustive of domains with problems, it primarily lists only those who are subscribers of linux-kernel, and thus accumulated (al lot) more than 1 email with "connection timed out" status into vger's queue. DEST. DOMAIN SERVER NAME ic.sunysb.edu -> bartman.ic.sunysb.edu olympus.phys.wesleyan.edu -> olympus.phys.wesleyan.edu imap.reed.edu -> imogen.reed.edu aplcomm.jhuapl.edu -> dallas.jhuapl.edu mail.utexas.edu -> mx2.mail.utexas.edu cs.jhu.edu -> hops.cs.jhu.edu judy.indstate.edu - gets connected, but then freezes. cc.usu.edu -> cc.usu.edu aubi.de -> mail.aubi-online.de opensource.se -> mail.carambole.com routemeister.net-> mail.carambole.com *.swipnet.se-> smtp-ext.swip.net swipnet.se -> smtp-ext.swip.net get2net.dk -> smtp-ext.swip.net dina.kvl.dk -> sheridan.dina.kvl.dk enea.se -> ruff.enea.se able.es -> jalon.able.es vadoc.state.va.us -> mail.vadoc.state.va.us libero.it -> smtp-in.libero.it ra.cit.alcatel.fr -> mail.alcatel.fr csse.monash.edu.au -> ld-mx.it.monash.edu.au galactica.it-> mail.galactica.it ds.catv.ne.jp -> cs14.catv.ne.jp mailbox.dsnet.it-> mailin.dsnet.it lee.k12.nc.us -> shomer.lee.k12.nc.us sh.bel.alcatel.be -> mx001.alcatel.be quantum.cicese.mx -> quantum.cicese.mx isuzu.pl-> isztye02.isuzu.pl gruppocredit.it -> mext.gruppocredit.it debitel.net -> mail.dnsg.net optical.lvl.pri.bms.com -> chimera.bms.com us.celoxica.com -> mail.us.embeddedsol.com ford.com-> mail0.allegro.net vnnews.com -> mail.cinet.vnn.vn echostar.com-> rf-mail1.echostar.com jetform.com -> mail.jetform.com half.com-> mailhub.half.com pa.dec.com -> ztxmail01.ztx.compaq.com compaq.com -> ztxmail01.ztx.compaq.com zk3.dec.com -> ztxmail01.ztx.compaq.com allaire.com -> smtp.allaire.com catalog-international.com -> ciexchange.catalog-international.com lcr-m.com -> mail1.lcr-m.net logica.com -> mail4.messagelabs.com missioncriticallinux.com-> mail.missioncriticallinux.com msdw.com-> mx1.ms.com honeywell.com -> tmpsmtp702.honeywell.com austin.ibm.com -> mg02.austin.ibm.com btinternet.com -> moongate.btinternet.com geeksimplex.org -> DNS A: 24.18.90.197 (home.com cable) - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFD w/info-PATCH] device arguments from lookup, partion code
> For _devices_, though? I don't expect my mouse to work if gpm and xfree > both try to consume device events from the same filp. Heck, it doesn't > even work when they try to consume events from the same inode :-) I think > this is a reasonable restriction for the class of devices in question. Not really. Think about basic things like full duplex audio with two threads - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
