On Thu, 1 Mar 2001, Alan Cox wrote:
> > In that case, why was it changed for FAT only? Ext2 will still
> > happily enlarge a file by truncating it.
>
> ftruncate() and truncate() may extend a file but they are not required to
> do so.
>
> > If the behavior has to be changed, wouldn't it be be
On Thu, 1 Mar 2001, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> Alexander Viro <[EMAIL PROTECTED]> wrote:
> >
> >Alan, fix is really quite simple. Especially if you have vmtruncate()
> >returning int (ac1 used to do it, I didn
On Sat, 1 Jan 2000, Pavel Machek wrote:
> Hi!
>
> > I was hoping to point out that in real life, most systems that
> > need to access large numbers of files are already designed to do
> > some kind of hashing, or at least to divide-and-conquer by using
> > multi-level directory structures.
>
On Thu, 1 Mar 2001, Roman Zippel wrote:
> Hi,
>
> On Thu, 1 Mar 2001, Alexander Viro wrote:
>
> > +static int generic_vm_expand(struct address_space *mapping, loff_t size)
> > +{
> > + struct page *page;
> > + unsigned long index, offset;
> &g
On Thu, 1 Mar 2001, H. Peter Anvin wrote:
> > * userland issues (what, you thought that limits on the
> > command size will go away?)
>
> Last I checked, the command line size limit wasn't a userland issue, but
> rather a limit of the kernel exec(). This might have changed.
I _really
On Fri, 2 Mar 2001, Pavel Roskin wrote:
> Hello!
>
> I understand that root can do many strange and unsafe things, but mounting
> the same filesystem many times is not allowed for systems other than
> usbdevfs.
Mounting the same fs many times _is_ perfectly legitimate. However, I really
don't
On Fri, 2 Mar 2001, Alexander Viro wrote:
> I.e. replace the last argument in declaration of usbdevfs with FS_SINGLE -
> without that we get a new instance every time.
Grr... Proper patch follows. Please, apply.
On Fri, 2 Mar 2001, TimO wrote:
> eax: ebx: ecx: edx:
[snip]
> >>EIP; c0142a52<=
> Trace; c0142ca6
> Trace; c0145f01
> Trace; c014601a
> Trace; c01349a4
> Trace; c0134f7a
> Trace; c0107007
> Trace; c01074b8
> Code; c0142a52
> <_EI
[sorry for sel-followup, but...]
> Lovely. sb->s_op == NULL in iget(). The thing being, proc_read_super()
> explicitly sets ->s_op to non-NULL. Oh, and that area hadn't changed since
> 2.4.2, so I'd rather suspect the b0rken build. Can you reproduce it?
More specifically, make sure that you
On Sat, 3 Mar 2001, Denis Perchine wrote:
> Hello,
>
> actually the question is in subj.
> Problem is that there is a program which needs to know physical memory
> size. This information is used to justify memory consumption as after some
> swapping performance is drops dramatically, and it is
On 3 Mar 2001, Michael Rothwell wrote:
> pyhsmem = `free | grep Mem | tr -s "/ / /" | cut -f2 -d" "`
% strace free 2>&1 |grep /proc
open("/proc/cpuinfo", O_RDONLY) = 3
open("/proc/uptime", O_RDONLY) = 3
open("/proc/stat", O_RDONLY)= 4
open("/proc/meminfo", O_RDONLY
[cc trimmed]
On Sat, 3 Mar 2001, Alan Cox wrote:
> > Long ago, pre* and ac* patches were rare. Patches went from one
>
> Umm wrong. -ac patches for 2.2 regularly did one a day
>
> > line-by-line before the next one came out. Patches always applied
> > easily with the (pre-POSIX?) patch comman
On Sat, 3 Mar 2001, Jens Axboe wrote:
> On Sat, Mar 03 2001, [EMAIL PROTECTED] wrote:
> >
> > I have an encrypted filesystem mounted over loopback that I created under
> > a 2.2.16 kernel. (Using AES, 128 bit key.) Works fine in 2.2.16. Sort of
> > works under the unpatched 2.4 series. (Mounts
On Sat, 3 Mar 2001, Jens Axboe wrote:
> On Sat, Mar 03 2001, Alexander Viro wrote:
> > > Look for the patch I posted yesterday (hint: just remove these two
> > > lines from loop_end_io_transfer)
> > >
> > >
On Mon, 5 Mar 2001, Alan Cox wrote:
> o Fix binfmt_misc (and make the proc handling (Al Viro)
> |a filesystem -
> |mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
One comment: probably the best way to maintain backwards compatibility
for people who used binfmt_misc as a
On Tue, 6 Mar 2001, Urban Widmark wrote:
>
> Is it valid to call d_add on a negative dentry?
> (or on a dentry that is already linked in d_hash, but all negative
> dentries are, right?)
Not all of them. It _is_ legal to do d_add() on a negative dentry.
Doing that for hashed dentries is a bug
On Mon, 5 Mar 2001, J . A . Magallon wrote:
>
> On 03.05 Sergey Kubushin wrote:
> > On Mon, 5 Mar 2001, Alexander Viro wrote:
> >
> > New Adaptec driver does not build. It won't. People, can anyone enlighten me
> > why do we use a user space library for a
On Tue, 6 Mar 2001, Alan Cox wrote:
> > Yuck. Build-dependency on libdb-dev is not pretty. What is it used for,
> > anyway? Assembler in need of libdb. Mind boggleth...
>
> Could it perhaps be persuaded to use Tridge's tdb, which at < 1000 lines could
> simply be included with it...
Alan, AFA
On Wed, 3 Jan 2001, Oliver Xymoron wrote:
> On Wed, 3 Jan 2001, Alexander Viro wrote:
>
> > On Wed, 3 Jan 2001, Stephen C. Tweedie wrote:
> >
> > > Having preallocated blocks allocated immediately is deliberate:
> > > directories grow slowly and re
On Thu, 4 Jan 2001, Chris Mason wrote:
> Hi guys,
>
> Looks like the prerelease, and at least test13 don't fsync the device when
> someone does an unmount on /
>
> mount -o remount works, just unmounting the root misses the fsync.
>
> This patch works for me:
>
> -chris
>
> --- linux/fs/su
On Thu, 4 Jan 2001, Stephen C. Tweedie wrote:
> The problem with directories is that they don't always grow rapidly
> like that. Spool directories are perfect examples of directories
> which grow sporadically over a long time, which is why we wanted
> persistent preallocation.
OK... It could
On Sat, 6 Jan 2001, Stefan Traby wrote:
> Then I tried to unlink the file by running rm lfs.file log.
>
> The rm process (and an ls process that I started after that)
> are now in "D" state...
>
> root 2934 0.0 0.2 1292 452 pts/5D05:38 0:00 ls /ramfs
> root 2952 0.0
On Sat, 6 Jan 2001, Stefan Traby wrote:
> On Fri, Jan 05, 2001 at 11:52:31PM -0500, Alexander Viro wrote:
> > On Sat, 6 Jan 2001, Stefan Traby wrote:
> >
> > > Then I tried to unlink the file by running rm lfs.file log.
> > >
> > > The rm process (a
On Mon, 8 Jan 2001, Robert Wienholt, Jr. wrote:
> Gentlemen,
>
> I was looking through some of the memory management code today and
> came across something that may provide a minor performance boost. I have
> included a patch below for the 2.4.0 source.
>
> In the find_vma functi
On Sat, 6 Jan 2001, Alan Cox wrote:
> > > > Add UnlockPage(page) at the end of ramfs_writepage().
> > > Shit. You are quite fast. Works.
> >
> > Sure, especially considering the fact that patch was sent to
> > Linus about a month ago (several times, actually)... ;-/
>
> Its in all the -ac
On Sun, 7 Jan 2001, Chris Wedgwood wrote:
> On Sat, Jan 06, 2001 at 03:35:32PM +, Alan Cox wrote:
>
> BTW Al: We have another general vfs/fs problem to handle - which
> is exceeding max file sizes on limited file systems. Pretty much
> nobody is getting it right. Ext2 can be tr
On Mon, 8 Jan 2001, Chris Wedgwood wrote:
> On Mon, Jan 08, 2001 at 02:56:10AM -0500, Alexander Viro wrote:
>
> Plenty. ext2, for one - e.g. with 4Kb blocks you have limit
> at 0x4010040c000 for files and 0x1 for directories. With
> 1Kb blocks the lim
On Mon, 8 Jan 2001, Alan Cox wrote:
> > Alan, it doesn't work that way. Maximal size depends on the type of object,
> > for one thing. Moreover, it's not always a multiple of page size, so you
>
> Its a multiple of page size for all fs's we have but I did it in terms of
> bytes anyway
1Kb-blo
On Mon, 8 Jan 2001, Alan Cox wrote:
> > > I put it into generic_file_write. That covers most fs's it seems. The jffs
> > > guys are going to switch to generic_file_write soon and the other fs's
> > > that dont are wacko ones I dont care about ;)
> >
> > Alan, we have to deal with get_block()
On Mon, 8 Jan 2001, Stefan Traby wrote:
> On Mon, Jan 08, 2001 at 12:26:17PM +, Alan Cox wrote:
>
> > I can put all that in the VFS so I did (right now the ext2 size calculator is
> > wrong but thats proof of concept detail). Just need to shift if over from
> > ext2/file.c
>
> Try 'getcon
On Mon, 8 Jan 2001, Ingo Oeser wrote:
> Then we might need W bits, but currently they disturb things like
> "test" and the perl equivalent, which is quite annoying and
> complexifies code. (Yes, I'm selfish too ;-))
Huh??? Consider write-protected floppy. What, you mean that it also
should ma
Alan, consider applying the patch below.
Contents:
* recovery from failing get_block() in __block_write_full_page()
and __block_prepare_write().
* handling of partially mapped pages in generic_file_write().
* use of ->s_maxbytes in default_llseek().
* crapectomy in
On Mon, 8 Jan 2001, Stefan Traby wrote:
> Because I have no knowledge on this I suggest that you and Ulrich fight
> together on a more flexible solution than the current one. I guess
> that Linus would accept this without thinking too much about it.
Unfortunately, Ulrich's taste was incompatib
On Mon, 8 Jan 2001, Alan Cox wrote:
> > > Why not start to fix this problem outside the funny switch/case in glibc ?
> > > The filesystem itself should able to handle this.
> >
> > Sigh... And the API would be?
>
> In SuS its pathconf()
Which happens to be remarkably ugly. And it will not ge
On Mon, 8 Jan 2001, Alan Cox wrote:
> > Which happens to be remarkably ugly. And it will not get better tomoorow...
>
> Its really only ugly in one way which is that you pass an int for the item
> rather than having a struct of all the data
You know as well as I do that as soon as we add it g
On Mon, 8 Jan 2001, Chris Mason wrote:
>
>
> On Monday, January 08, 2001 09:02:46 AM -0500 Alexander Viro
> <[EMAIL PROTECTED]> wrote:
>
> > Alan, consider applying the patch below.
> > Contents:
> [snip]
> > + do {
> > + if
On Mon, 8 Jan 2001, Chris Mason wrote:
>
> On Monday, January 08, 2001 10:47:41 AM -0500 Alexander Viro
> <[EMAIL PROTECTED]> wrote:
> > + do {
> > + if (buffer_mapped(bh)) {
> > + bh->b_end_io = end_buffer_io_async;
&g
On Mon, 8 Jan 2001, Andrea Arcangeli wrote:
> Hello Al,
>
> why `rmdir .` is been deprecated in 2.4.x? I wrote software that depends on
> `rmdir .` to work (it's local software only for myself so I don't care that it
> may not work on unix) and I'm getting flooded by failing cronjobs since I
On Mon, 8 Jan 2001, Andrea Arcangeli wrote:
> in userspace, but I think the old behaviour was more flexible (it was also
> showing how much our dcache is powerful) and I still don't see why it's been
> removed. Maybe it was to remove a branch from a fast path? (if so I don't
> think it was a g
On Mon, 8 Jan 2001, Stefan Traby wrote:
> On Mon, Jan 08, 2001 at 04:01:10PM +, Alan Cox wrote:
> > > I prefer SuS fpathconf(), pathconf() is just a wrapper to fpathconf();
> >
> > You can't implement it that way in the corner cases.
>
> I reread SuSv2 again and didn't found corner cases.
On Mon, 8 Jan 2001, Stefan Traby wrote:
> Calling pathconf with a symlink is not defined. I suggest
> an implementation of "yankee doodle" for that case.
> Anyway the broken SuS standard wants that pathconf follow symlinks.
> Or how do you interpret this:
>
> [ELOOP]
>Too many sym
On Mon, 8 Jan 2001, Stefan Traby wrote:
> On Mon, Jan 08, 2001 at 01:22:49PM -0500, Alexander Viro wrote:
>
> > Here's another one: suppose that /foo is a mountpoint and you have
> > no read permissions on it. Try to open the thing...
>
> I would return EACCESS.
On Mon, 8 Jan 2001, Marc Lehmann wrote:
> On Mon, Jan 08, 2001 at 01:33:50PM -0500, Alexander Viro <[EMAIL PROTECTED]> wrote:
> > And prefix would be what? "/"? Besides, I said that you don't have
> > read permissions on /foo, not search ones.
>
> Y
On Mon, 8 Jan 2001, Andreas Dilger wrote:
> Actually, this is wrong. The ext2 inode limit is 2^32 512-byte sectors,
> not 2^32 blocksize blocks. Yes this is a wart and Ted wants to fix it, as
??? Where? Oh, wait... ->i_blocks? I'ld rather refuse to grow past 2^32 -
sparse files can legitimat
On Mon, 8 Jan 2001, Andrea Arcangeli wrote:
> On Mon, Jan 08, 2001 at 01:04:24PM -0500, Alexander Viro wrote:
> > Racy. Nonportable. Has portable and simple equivalent. Again, don't
> > bother with chdir at all - if you know the name of directory even
> > ../name wil
On Mon, 8 Jan 2001, Stefan Traby wrote:
> On Mon, Jan 08, 2001 at 12:58:20PM -0500, Alexander Viro wrote:
>
> > Shell equivalent is rmdir `pwd`. Also portable.
>
> Very portable - not.
>
> rmdir "`pwd`" !!!
OK, got me on that. Yes, you'll need
On Tue, 9 Jan 2001, Jesse Pollard wrote:
> Not exactly valid, since a file could be created in that "pinned" directory
> after the rmdir...
No, it couldn't (if you can show a testcase when it would - please do, you've
found a bug). Moreover, busy directories can be removed in 2.4 quite fine -
On Tue, 9 Jan 2001, Albert D. Cahalan wrote:
> Alexander Viro writes:
>
> > [...] If you really need to destroy the directory
> > that happens to be your pwd - sorry, no reliable way to do that without
> > interesting locking. On _any_ UNIX out there. 2.2 included.
On 9 Jan 2001, Mathieu Chouquet-Stringer wrote:
> I use GRUB to boot my system. Basically, when you want to install GRUB on a
> floppy disk, you do that:
>
> dd if=stage1 of=/dev/fd0 bs=512 count=1
> dd if=stage2 of=/dev/fd0 bs=512 seek=1
>
> But since kernel 2.3.xx (I don't remember exactly)
On Tue, 9 Jan 2001, Albert D. Cahalan wrote:
> As long as nobody tried to remove ".", nothing is serialized.
> You can do your lookups in parallel since they can all grab
> the read lock at once.
Bzzzert. At which point do you take that lock for rmdir("foo/bar/barf/.")?
> Linux can tell where
On Tue, 9 Jan 2001, Alan Cox wrote:
> > dd bug. It tries to ftruncate() the output file and gets all upset when
> > kernel refuses to truncate a block device (surprise, surprise).
>
> Standards compliant but unexpected.
dd is supposed to be portable. On Solaris:
% man ftruncate
[snip]
On Wed, 10 Jan 2001 [EMAIL PROTECTED] wrote:
> >> dd: advancing past 1 blocks in output file `/dev/fd0': Permission denied
>
> > dd bug. It tries to ftruncate() the output file and gets all upset when
> > kernel refuses to truncate a block device (surprise, surprise).
>
> Yes. But EPERM means
On Tue, 9 Jan 2001, Chris Mason wrote:
>
>
> On Wednesday, January 10, 2001 02:32:09 AM +0100 Marc Lehmann <[EMAIL PROTECTED]> wrote:
>
> >>> EIP; c013f911<=
> > Trace; c013f706
> > Trace; c0136e01
>
> The buffer reiserfs is sending to filldir is big enough for
> the huge file nam
On Wed, 10 Jan 2001, Andrea Arcangeli wrote:
> > Do we have enough protection to ensure this for other filesystems?
>
> Note that this has nothing to do with `rmdir .`. You will run into the
> mentioned issue just now with '''rmdir "`pwd`"'''. I've not checked
> the other fses but I would put
On Wed, 10 Jan 2001, Chris Mason wrote:
>
>
> On Wednesday, January 10, 2001 12:47:17 AM -0500 Alexander Viro
> <[EMAIL PROTECTED]> wrote:
>
> > However, actual code really looks like the end of filldir(). If that's the
> > case we are deep in it - a
On Wed, 10 Jan 2001, Chris Mason wrote:
> Ah thanks, that makes more sense. But, copy_to_user is only working on
> namelen bytes, and reclen is bigger than that. So, who is checking the
> value for the buf->current_dir pointer?
Look at the thing again. Especially at the place where reclen is
Patch updates filesystems/Locking - corrects ->writepage()
prototype, removes dead vma methods and corrects ->writepage() and
->readpage() description wrt page lock.
Please, apply.
diff -urN S1-pre1/Documentation/filesystems/Locking
S1-pre1-s_lock/Documentation/filesystems/Locki
On Thu, 11 Jan 2001, Daniel Phillips wrote:
> "Udo A. Steinberg" wrote:
> > Upon fscking after reboot, I always have errors on a
> > single inode and it's always the same one:
> >
> > /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED
> >
> > Can someone tell me an easy and reliable
On Thu, 11 Jan 2001, Stephen C. Tweedie wrote:
> Hi,
>
> On Wed, Jan 10, 2001 at 12:11:16PM -0800, Linus Torvalds wrote:
> >
> > That said, we can easily support the notion of CLONE_CRED if we absolutely
> > have to (and sane people just shouldn't use it), so if somebody wants to
> > work on
On Thu, 11 Jan 2001, Stephen C. Tweedie wrote:
> Hi,
>
> On Thu, Jan 11, 2001 at 02:12:05PM +0100, Trond Myklebust wrote:
> >
> > What's wrong with copy-on-write style semantics? IOW, anyone who
> > wants to change the credentials needs to make a private copy of the
> > existing structure fi
On Thu, 11 Jan 2001, Stephen C. Tweedie wrote:
> > And how is that different from the current situation?
>
> It's not, which is the point I was making: COW doesn't actually solve
> the pthreads problem. Far better to do it in user space.
Oh, certainly. We need COW for completely unrelated re
On Thu, 11 Jan 2001, Udo A. Steinberg wrote:
> > /dev/hdb1: Inode 522901, i_blocks is 64, should be 8. FIXED
> umount: none busy - remounted read-only
> The "none" bit puzzles me the most. /etc/fstab and /etc/mtab
> look perfectly ok.
>
> Has anyone got an idea? Everything worked well with
rpc_release_task is required by nfs.o.
--- net/sunrpc/sunrpc_syms.cFri Apr 21 19:08:52 2000
+++ net/sunrpc/sunrpc_syms.cThu Jan 11 18:01:50 2001
@@ -36,6 +36,7 @@
EXPORT_SYMBOL(rpciod_up);
EXPORT_SYMBOL(rpc_new_task);
EXPORT_SYMBOL(rpc_wake_up_status);
+EXPORT_SYMBOL(rpc_re
On Fri, 12 Jan 2001, Chris Mason wrote:
>
> Hi guys,
>
> This code for generic_file_write calls vmtruncate without i_sem held. Is
> that intentional? It should cause problems for reiserfs at least...
Erm... generic_file_write() grabs i_sem upon entry and drops it on exit.
This call of vmtr
On Tue, 14 Nov 2000, Juan wrote:
> Hi!.
>
> Is there any patch or project to address logically the buffer cache?.
> Now, you use three parameters to find a buffer in cache: device, block
> number, and block size. But, what about if I want to find a buffer using
> a super block, an inode number
On Tue, 14 Nov 2000, Richard B. Johnson wrote:
> On Tue, 14 Nov 2000, Michael Rothwell wrote:
>
> > "Richard B. Johnson" wrote:
> > > Multics??? [..] way too many persons on this list who know the history of
> > > Unix to try this BS.
> >
> > So, you're saying their nine goals were bullshit?
On Tue, 14 Nov 2000, Jeff Garzik wrote:
> Since I am not a block device expert, I am interested to know if
> these fixes look ok, and if they fix the reported loopback deadlocks.
>
> I added calls to deactive_page and flush_dcache_page, and made sure
> that any error returns were propagated ba
* baycom_epp: yet another missed x86_capability instance.
* soundmodem/sm.h: ditto.
* wan/comx.c: fixed typo in call of remove_proc_entry() (the second
argument is proc_dir_entry *, not **)
* scsi/gdth.c::gdth_flush() had a path with use of uninitialized
variable:
On Thu, 16 Nov 2000, Mikael Pettersson wrote:
> I noticed because I needed to build a boot floppy with an
> initial ram disk under 2.4.0-test11pre5. The standard recipe
> (Documentation/ramdisk.txt) basically goes:
> - dd if=bzImage of=/dev/fd0 bs=1k
> notice how many blocks dd reported (NNN)
On Thu, 16 Nov 2000, Mikael Pettersson wrote:
> On Thu, 16 Nov 2000, Alexander Viro wrote:
>
> > And what kind of meaning would you assign to truncate on floppy?
>
> On a block or char device, truncate == lseek seems reasonable.
Huh? On regular files ftruncate() doesn&#x
Almost all (== all filesystem and then some) callers of
get_empty_inode() follow it with
inode->i_sb = some_sb;
inode->i_dev = some_sb->s_dev;
Some of them do it twice for no good reason (assign the same value,
even though neither ->i_sb nor ->i_dev could change in interval
On Thu, 16 Nov 2000, Tigran Aivazian wrote:
> on the other hand, even 1 minute's thought reveals that making strict
> logical separation between "consumers of inode with sb" and "consumers of
> inode without sb" is probably worth the overhead of an extra function
> call. So, I don't strongly fe
On Thu, 16 Nov 2000, Linus Torvalds wrote:
> The cwd is not the problem. The '.' is.
>
> The reason for that check is that allowing "rmdir(".")" confuses a lot of
> UNIX programs, because it wasn't traditionally allowed.
Moreover, allowing it means that you overload the semantics of rmdir()
(
On Thu, 16 Nov 2000, Alan Cox wrote:
> > The only disadvantage to this scheme is the added cost of a kernel
> > thread over a kernel timer. I think this is an ok cost, because this
> > is a low-impact thread that sleeps a lot..
>
> 8K of memory, two tlb flushes, cache misses on the scheduler.
On Thu, 16 Nov 2000, Jean-Marc Saffroy wrote:
> On Thu, 16 Nov 2000, Linus Torvalds wrote:
>
> > The cwd is not the problem. The '.' is.
> >
> > The reason for that check is that allowing "rmdir(".")" confuses a lot of
> > UNIX programs, because it wasn't traditionally allowed.
>
> This is a
On Thu, 16 Nov 2000, Jean-Marc Saffroy wrote:
> Now I see your point : by "." or "foo/." you mean the directory itself,
> while "foo" or "foo/" refer to the link to the directory, and they are
> obviously different objects... at least since hard links on directories
> were introduced. Fine.
So
On 16 Nov 2000, H. Peter Anvin wrote:
[hardlinks on directories]
> I don't believe it's inherently impossible in Linux anymore. In fact,
Yes, it is. bindings are asymmetrical. And that's the reason why they
work while links to directories do not.
> vfsbinds provide a lot of the same kind o
On Thu, 16 Nov 2000, David Feuer wrote:
> At 06:10 PM 11/16/2000 -0500, you wrote:
> >Here's one more: you can't rename across the binding boundary. They _are_
> >mounts, so they avoid all that crap with loop creation on rename, etc.
> >Take a generic DAG and try to implement rename() analog on
* Arrgh. Hell knows how, but %s/new_inode/ntfs_&/g in fs/ntfs/inode.c
mentioned in the previous part didn't make it into the patch I've sent.
Mea maxima culpa. Fixed.
* More duplicated initializations removed:
* get_empty_inode() sets i_flags to 0. NFS and UDF did t
On Fri, 17 Nov 2000, Frank Davis wrote:
> Hello,
> I just try to compile 2.4.0-test11-pre6, and received the following error (make
>modules):
>
> inode.c:1054 conflicting types for 'new_inode'
> /usr/src/liunux/include/linux/fs.h:1153 previous declaration of 'new_inode'
My fault. Hell know
* fs_may_remount_ro() used the wrong check for skipping the
files being in the middle of final fput(). NULL ->f_dentry is
possible here (after all references to file are gone, etc.), NULL
->f_dentry->d_inode isn't. I.e. check in
file_list_lock();
for (p = sb->s_files.next;
On Fri, 17 Nov 2000, Guest section DW wrote:
> I see that an entire discussion has taken place. Let me just remark this,
> quoting the Austin draft:
>
> If the path argument refers to a path whose final component is either
> dot or dot-dot, rmdir( ) shall fail.
>
> EINVALThe path argu
On Fri, 17 Nov 2000, Jeff V. Merkey wrote:
>
> This is probably a configuration mismatch of some kind, but I just
> finished building my 2.4.0 RPM skeletons and am installting them from
> our latest CD burn, and I am seeing the following
> problem when I upgrade our 2.2.17 kernel versio
On 18 Nov 2000, Nix wrote:
> Alexander Viro <[EMAIL PROTECTED]> writes:
>
> > If every way from foo to target goes through the source rename(source,target)
> > _will_ make the graph disconnected. Checking that for generic DAG is a hell.
>
> Why do you say this?
On Sun, 19 Nov 2000, David Lang wrote:
> there is a rootkit kernel module out there that, if loaded onto your
> system, can make it almost impossible to detect that your system has been
> compramised. with module support disabled this isn't possible.
Yes, it is. Easily. If you've got root you
On Sun, 19 Nov 2000, Christer Weinigel wrote:
> In article <[EMAIL PROTECTED]> you write:
> >On Sun, 19 Nov 2000, Alexander Viro wrote:
> >> On Sun, 19 Nov 2000, David Lang wrote:
> >> > there is a rootkit kernel module out there that, if loaded onto yo
On Tue, 21 Nov 2000, Jan Kara wrote:
> Hello.
>
> After rewrite of umount checks some time ago (just now reading your mail
> I realized I never asked) filesystem doesn't umount when quotas are
> turned on on it - it fails on check (atomic_read(&mnt->mnt_count) > 2)
> in do_umount().
> Is
On Thu, 23 Nov 2000, Neil Brown wrote:
> Oh, good. It's not just me and Tigran then. I was at first blaming
> my raid5 code for this, but if you get it and Tigran gets it (reported
> http://boudicca.tux.org/hypermail/linux-kernel/2000week48/0257.html
> ) then it's probably not me.
>
> And
On Thu, 23 Nov 2000, Neil Brown wrote:
> which enabled ext2_notify_change, however ext2_notify_change has a
> bug.
> It sets attributes from iattr->ia_attr_flags even
> if ATTR_ATTR_FLAG is NOT SET in iattr->ia_valid.
Arrrgh. Could you try that:
diff -urN rc11/fs/buffer.c rc11-ext2/fs/buffer.
On Thu, 23 Nov 2000, Alexander Viro wrote:
> On Thu, 23 Nov 2000, Neil Brown wrote:
>
> > which enabled ext2_notify_change, however ext2_notify_change has a
> > bug.
> > It sets attributes from iattr->ia_attr_flags even
> > if ATTR_ATTR_FLAG is NOT SET in ia
* maximal allowed size is calculated during the ext2_read_super()
and stored in sb->u.ext2_sb.s_max_size. ext2_file_lseek() uses it instead
of the (rather ugly) tricks with ext2_max_sizes[]. Cleaner, more effecient
and IMO more readable.
* ext2_notify_change() is used as ->setattr(
On Thu, 23 Nov 2000, Matti Aarnio wrote:
> On Thu, Nov 23, 2000 at 12:38:55PM -0800, Linus Torvalds wrote:
> ...
> > In fact, almost all filesystems do this at some point. ext2 does it for
> > directories too, for some very similar reasons that isofs does. See
> > fs/ext2/dir.c:
> >
> > b
On Thu, 23 Nov 2000, Gregory Maxwell wrote:
> On Fri, Nov 24, 2000 at 02:57:45AM +0100, [EMAIL PROTECTED] wrote:
> > but in the meantime there is good confirmation.
> > This really is a bug in gcc 2.95.2.
>
> ... RedHat's GCC snapshot "2.96" handles this case just fine.
Now, if you can isola
On Fri, 24 Nov 2000, Neil Brown wrote:
> I ran my test script, which builds a variety of raid5 arrays with
> varying numbers of drives and chunk sizes, and runs mkfs/bonnie/dbench
> on each array, and it got through about 8 file systems but choked on
> the 9th by trying to allocate lots of bloc
On Fri, 24 Nov 2000, Mohammad A. Haque wrote:
> I got the error while I was compiling XFree86 4 CVS and kernel. So
> that's what I've been doing in multiples along witha couple otehr things
> thrown inthe mix to generate lots of disk i/o.
Error messages would be interesting... So far we have _
On Thu, 23 Nov 2000, Andre Hedrick wrote:
> What the F*** does that have to do with the price of eggs in china, heh?
> Just maybe if you could follow a thread, you would see that that Alex Viro
> has pointed out that changes in the FS layer as dorked things.
?
If you have a l-k feed from futur
On Fri, 24 Nov 2000, Neil Brown wrote:
> Ditto for gcc-2.95.2-13 from Debian (potato). It exhibits the same
> bug.
> Debian applies a total of 49 patches to gcc and the libraries.
>
> I am tempted to write a little script which discards the patches one
> by one and re-builds and re-tests each
On Thu, 23 Nov 2000, Andre Hedrick wrote:
[I wrote]
> > ?
> > If you have a l-k feed from future - please share. I'm not saying that
>
> Date: Thu, 23 Nov 2000 04:37:21 -0500 (EST)
>
> > fs/* is not the source of that stuff, but I sure as hell had not said
> > that it is. I simply don't know
On Sun, 26 Nov 2000, Elmer Joandi wrote:
>
> Kernel has become so big that it really needs universal debugging macros
> instead of comments. Comments are waste of brain&fingerpower, if the same
> can be explained by long variable names and debug macros.
>
> static Subsystem_module_LocalVaria
On Mon, 27 Nov 2000, John Zielinski wrote:
> I'm going to be mounting a filesystem that uses a block device from inside
> the kernel. This mount will not be visible from userland nor can it be
> unmounted from userland. Is anyone else doing something like this so we can
> coordinate on the ch
101 - 200 of 969 matches
Mail list logo
