Re: quota deadlock in 2.4.5-pre4

2001-05-24 Thread Jan Kara
Hello, 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

Re: quota deadlock in 2.4.5-pre4

2001-05-24 Thread Jan Kara
Hello, There's also this recursion: write(user)-write_dquot(user)-write(quotafile)-write_dquot(root) This recursion isn't there any more (I think for something like 6 months). We simply don't have quotafiles counted to quota...

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)

2001-05-24 Thread Andreas Dilger
Linus writes: There are some strong arguments that we should have filesystem backdoors for maintenance purposes, including backup. You can, of course, so parts of this on a LVM level, and doing backups with disk snapshots may be a valid approach. However, even that is debatable: there is

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-24 Thread Malcolm Beattie
[cc list reduced] Andreas Dilger writes: PS - I used to think shrinking a filesystem online was useful, but there are a huge amount of problems with this and very few real-life benefits, as long as you can at least do offline shrinking. With proper LVM usage, the need to

Re: quota deadlock in 2.4.5-pre4

2001-05-24 Thread Andrew Morton
Jan Kara wrote: There are two quota formats: Ah. user error :) The first in Linus's tree - it uses file quota.user and it's simple flat file (and I agree that hole in it can cause deadlock :(). The second in Alan's tree - it uses file aquota.user and it has more complicated file

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)

2001-05-24 Thread Andreas Dilger
Malcolm Beattie writes: Andreas Dilger writes: PS - I used to think shrinking a filesystem online was useful, but there are a huge amount of problems with this and very few real-life benefits, as long as you can at least do offline shrinking. With proper LVM usage, the

CHR/BLK needed? was: Re: Why side-effects on open...

2001-05-24 Thread Marko Kreen
On Thu, May 24, 2001 at 09:39:35AM -0500, Oliver Xymoron wrote: On Thu, 24 May 2001, Marko Kreen wrote: IMHO the CHR/BLK is not needed. Think of /proc. In the future, the backup tools will be told to ignore /dev, that's all. The /dev dir should not be special. At least not to the

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-24 Thread Marko Kreen
On Thu, May 24, 2001 at 02:23:27AM +0200, Edgar Toernig wrote: Daniel Phillips wrote: It's going to be marked 'd', it's a directory, not a file. Aha. So you lose the S_ISCHR/BLK attribute. Readdir fills in a directory type, so ls sees it as a directory and does the right thing.

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-24 Thread Alexander Viro
On Thu, 24 May 2001, Edgar Toernig wrote: What *won't* happen is, you won't get side effects from opening your serial ports (you'd have to open them without O_DIRECTORY to get that) so that seems like a little step forward. As already said: depending on O_DIRECTORY breaks POSIX

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]devicearguments from lookup)

2001-05-24 Thread Oliver Xymoron
On Thu, 24 May 2001, Marko Kreen wrote: On Thu, May 24, 2001 at 02:23:27AM +0200, Edgar Toernig wrote: Daniel Phillips wrote: It's going to be marked 'd', it's a directory, not a file. Aha. So you lose the S_ISCHR/BLK attribute. Readdir fills in a directory type, so ls

Re: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)

2001-05-24 Thread Daniel Phillips
On Tuesday 22 May 2001 22:10, Andreas Dilger wrote: Peter Braam writes: 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.