Kernel Traffic #20 For 27 May 1999

By Zack Brown

Table Of Contents

• Printer-Friendly Format
• Text Format
• XML Source
• Introduction
• Mailing List Stats For This Week
• Threads Covered

  1.	12 May 1999 - 30 May 1999	(16 posts)	Remote Reboot Discussion
  2.	12 May 1999 - 20 May 1999	(20 posts)	Remounting A Filesystem Under A Different Directory
  3.	14 May 1999 - 21 May 1999	(34 posts)	'rm' Too Slow
  4.	16 May 1999 - 18 May 1999	(13 posts)	EFS Filesystem Appears In 2.3.2
  5.	16 May 1999 - 21 May 1999	(14 posts)	Debate Over 'goto' In Source
  6.	18 May 1999 - 22 May 1999	(10 posts)	Multiple Detection Of Hardware Since 2.2.3

Introduction

If I haven't responded to your email in the past week or so, sorry about that. It's hard to send email right now; but I've read and thought about each one, and I appreciate them very much.

You'll notice the article titles don't lead into the archive (and the quotes pages have fallen behind again). I'll take care of it as soon as I can (hopefully today).(OK, the titles lead into the archive at last. Still haven't updated the quotes pages yet -- Ed: [29 May 1999 00:00:00 -0800]

Mailing List Stats For This Week

We looked at 1061 posts in 4086K.

There were 436 different contributors. 181 posted more than once. 190 posted last week too.

The top posters of the week were:

• 32 posts in 147K by Riley Williams
• 32 posts in 124K by Andrea Arcangeli
• 25 posts in 92K by Alexander Viro
• 20 posts in 76K by Pavel Machek
• 18 posts in 58K by Richard Gooch
• Full Stats

1. Remote Reboot Discussion

12 May 1999 - 30 May 1999 (16 posts) Archive Link: "Clear reboot?"

Topics: FS, Security

People: Richard B. Johnson, Chris Wedgwood, Steve Dodd

David Guo rigged his machine to reboot when a certain port was triggered remotely. The only problem was that the disks weren't being correctly umounted before the reboot, so they were going through fsck on every startup. He figured the way to solve this was to do a sync before each reboot, and wanted to know how to handle that. He got a number of suggestions on the list, and there was some general discussion about triggering reboots.

Several people replied independently to his post: Chris Wedgwood had one of the most direct answers, pointing out that, before rebooting, David could do a sys_sync(). David B. Rees suggested running the 'shutdown' script, or failing that, remounting all partitions read-only via system call before rebooting. Steve Dodd felt the whole idea belonged in user space, as a daemon which would invoke 'shutdown'. Richard B. Johnson also posted the C code of a 'reboot' program he'd written, saying, "This will run even if you booted the kernel with a shell instead of init."

Some folks felt it would be dangerous to have any kind of remote reboot feature without adding proper security. Chris was particularly disturbed by the idea (though he admitted having tried it a couple times himself). He definitely felt the mainstream kernel was not the place for such a thing.

2. Remounting A Filesystem Under A Different Directory

12 May 1999 - 20 May 1999 (20 posts) Archive Link: "[VFS] move active filesystem"

Topics: FS

People: Matthew Wilcox, Alexander Viro

Matthew Wilcox submitted a patch to Alexander Viro and they had a staircase about it. The patch allowed a user to specify a new directory when remounting a filesystem. The only problem, as Alexander pointed out, was that the patch allowed a filesystem to be remounted as a subdirectory of the directory it had previously been mounted on, thus detaching it from the main directory tree and making it inaccessible. Matthew felt this was really a minor issue, since root had so many other ways of trashing things, and in any case, the filesystem could always be re-attached with a subsequent command. Alexander described a few exploits, and was also worried about races, since all previous analysis of potential races assumed that the mountpoints never moved. Even if no races came up, he felt Matthew's code would still invalidate the earlier analysis.

Matthew was convinced. He agreed to put in a check to make sure the current mount point was not a prefix of the new mount point, but wondered where would be the best place to add that check. They were moving into an area he wasn't so familiar with. But after some explanation from Alexander, Matthew posted a revised patch.

3. 'rm' Too Slow

14 May 1999 - 21 May 1999 (34 posts) Archive Link: "Deletion of big files..."

Topics: FS: ext2

People: Theodore Y. Ts'o, Jan Kara, Rogier Wolff, Pavel Machek, Alexander Viro, Rik van Riel

Jorge Gonzalez Villalonga felt that rmming big files took too much time, as opposed to other systems which returned immediately. He felt the solution was to simply have the unlink() syscall do its work in the background. Rik van Riel suggested just running the 'rm' command in the background instead, but other folks got interested in the whole question.

Pavel Machek pointed out that with unlink() in the background, it would be possible to run out of disk space even after giving the rm command, if you used a lot of space before the unlink() had finished.

Alexander Viro pointed out that the real slowdown was not in unlink() but in truncate(), and he came up with an idea for having queues of objects to delete, in a kernel thread that keeps track of them and deletes them.

Theodore Y. Ts'o came in with a warning: "Careful here. One the reasons why truncate is so complicated is that we are *not* always the sole owners of the file. This comes up because truncate() isn't just called from unlink. It can also be called from ftruncate(), or from open() with O_TRUNC. A lot of the hair in truncate() is to deal with the case where another process as file descriptor open the file and is actively writing while truncate() is getting called." He added, "The right thing to do here is to replicate the truncate function so that there's one version that's used for unlink(), where you can make all sorts of simplifying assumptions, and one version which is used in the more general case."

Alexander had understood that but just not expressed himself clearly, but Pavel thought the whole thing might not be worth the effort.

Meanwhile, Rogier Wolff felt that the real problem was indirect blocks being scattered all over the disk. One solution, he said, was to fix the allocation routines; another was to make ext2fs use "extents" to keep track of where and how many blocks there were. Also, Jan Kara felt that Alexander's idea would actually increase disk fragmentation.

There were a lot of different ideas in this thread, but everyone seemed to agree that rm took too long.

4. EFS Filesystem Appears In 2.3.2

16 May 1999 - 18 May 1999 (13 posts) Archive Link: "EFS in 2.3.2 ???"

Topics: FS: EFS, FS: FAT, FS: XFS

People: Ralf Baechle, Tor Arntsen, Riley Williams

This was a very flat conversation: a lot of replies to the initial post, and very few replies to any of those replies. Riley Williams noticed that kernel 2.3.2 included a mysterious new filesystem, called EFS, completely undocumented, even in Configure.help.

Joel Klecker quoted the following from a page on the Extent File System: "The Extent File System (efs) is Silicon Graphics' early block-device filesystem, widely used on pre-6.0 versions of IRIX. Since 6.0, xfs has been bundled with IRIX and users are being encouraged to migrate to xfs filesystems. IRIX support for efs will be read-only in versions of IRIX beyond 6.5, however efs is still very much in use on SGI software distribution CDs." Ralf Baechle added (apparently before SGI's recent XFS announcement), "EFS is the filesystem that non-ISO9660 IRIX CDROMs are using. It's also being used for harddisks but has in IRIX 6.x been replaced by XFS - which we would be way cooler to have for Linux. The current EFS implementation seems to be stable but is unfortunately just r/o. Dunno if the current maintainer of EFS, Al Smith intends to make it r/w which would be way cooler for Linux / IRIX interoperability than FAT."

Elsewhere, Tor Arntsen said, "EFS doesn't support holes in files. EFS is useful for using a Linux box for CDROMs when you don't have a CDROM on your SGI box (SGI uses EFS on their CDs), and it's also useful when you're working with porting Linux to Indys and such."

One reply (lost from the archives but quoted by Riley) pointed to an LSM-type entry for EFS, and Riley posted a patch to put a description of EFS into Configure.help.

5. Debate Over 'goto' In Source

16 May 1999 - 21 May 1999 (14 posts) Archive Link: "schedule() 'spaghetti' in 2.3.2 .."

Topics: Coding Style

People: Rik van Riel, Andi Kleen, Jamie Lokier, Davide Libenzi

The last time this question came up in Kernel Traffic was at the end of January, in Issue #3, Section #1  (20 Jan 1999: 'goto' In The Sources) . This time, Davide Libenzi offered to rewrite the scheduling code to have fewer gotos. Rik van Riel explained, "The reason the code is 'spagettified' is to keep the cache footprint small and the scheduling overhead low (although I'm pretty sure we can save a few more picoseconds somewhere)." Andi Kleen added, "If gcc had a way to specify "move this block out of line" it could be writen in a more conventional way. ATM it hasn't. Any "fixes" for this style IMHO have to start with gcc," and Jamie Lokier said, "Egcs moves C++ exception handler blocks out of line, so I assume it would not be infeasible to add this optimisation. Discussion on the Egcs list a while back suggested it is possible but far from implemented."

6. Multiple Detection Of Hardware Since 2.2.3

18 May 1999 - 22 May 1999 (10 posts) Archive Link: "ide-scsi bug in 2.2.[3-9]"

Topics: Disks: IDE, Disks: SCSI

People: Bernhard Rosenkraenzer, Gadi Oxman, Riley Williams

Ever since kernel 2.2.3, Bernhard Rosenkraenzer's machine detected his CD drive and CD-writer devices several times during a single boot; it seemed like a bug to him, and he asked about it. Jorge Gonzalez Villalonga told him to turn off "Probe all LUNs on each SCSI device" in the kernel, corresponding to the CONFIG_SCSI_MULTI_LUN option in the .config file. Bernhard still felt the situation was a bug, saying, "It'll cause problems on boxes with, for example, an SCSI CD-Changer and an IDE CD-Writer (multi-lun required for the changer, but has to be turned off for the writer)." But Gadi Oxman interjected, "It's definitely not a bug; it's a feature, and there by design. multi-lun ATAPI devices do exist, and it's amazing how over the last two or three years so many people consider this to be a bug."

Riley Williams said, "The bug isn't that the config option exists, but that it's a generic option for all drives, as that will definately cause problems on systems where some drives need it set one way and some the other." He suggested making it a per-drive setting.

Sharon And Joy