Re: fs changes in 2.3
Hans Reiser wrote: Andi Kleen found a race condition for us, and told us where it was. Andi is cool. Viro found unecessary checks in our code, and then made it sound like something big. He does this kind of thing a lot to everyone. He discourages every contributor he can for the betterment of his ego. He is damage in the Linux community to route around. Here's a lesson in life: if you don't want to deal with somebody, don't deal with them. Al Viro isn't the only one allowed to contribute VFS patches. Jeff -- Jeff Garzik | Nothing cures insomnia like the Building 1024| realization that it's time to get up. MandrakeSoft, Inc. |-- random fortune
Re: umount in 2.3.99-pre4-5
"David S. Miller" wrote:
Date:Wed, 12 Apr 2000 01:30:42 +
From: Andrew Morton [EMAIL PROTECTED]
They say "device or resource busy" several times then give up,
leaving a dirty fs.
Does it actually run a full e2fsck on the filesystem upon
reboot?
Yes. I'm seeing it on Mandrake 7.0 and RedHat 6.2/Alpha.
My machines are often doing fsck-on-boot anyway due to normal kernel
development so it didn't concern me very much ;)
Jeff
--
Jeff Garzik | Nothing cures insomnia like the
Building 1024| realization that it's time to get up.
MandrakeSoft, Inc. |-- random fortune
Re: Ext2 / VFS projects
Caveat reader: With the exception of procfs stuff in 2.3.x, most of my VFS participation thus far has been of the "I want to work on this when I get time" sort of partitication. ;-) First, my request: Add an fcntl flag, O_NOCACHE (or O_DIRECT, unimplemented) which allows an app to hint that it does not want the OS to cache this data. This will be a _big_ win for servers and desktops where large multimedia or database files are slung around. Matthew Wilcox wrote: Btree directories (phil) I hope these are _not_ pure binary search trees but rather a smarter ADT... Backup inode table interesting idea fine-grained locking al viro was kind enough to e-mail me some of his thoughts on banishing the big kernel lock from the VFS. Though my time with the VFS has been nil in the past few months, I'd still like to work on this if noone beats me to it. IIRC the two big items are dcache/dentry and inode threading. Online defragmentation size Has there been any substantive discussion about online defragmentation? I think it is a wholly separate, and more interesting issue than resize (which will be solved in the future with LVMs, IMHO...) For online defrag, there are tons of different scenarios and hueristics which can be employed to optimize for various situations: * move frequently-accessed files to the middle of the disk (requires knowledge of physical disk organization, below the partition layer) * group files together on disk in directories, with gaps of free space in between for placement of files "near" other files in the same directory * options to pack files into inodes (if possible and supported by fs) or to fragment small files, to conserve space * dozens of hueristics. if online defrag is in userspace, admin can even craft their own disk optimization rules. Kernel changes Short term, the easiest implementation will be in-kernel. Long term, I would like to see (if possible) a set of generalized ioctls which allow a userspace program to contain the bulk of the defragmenting/disk optimization logic. Any and all ideas for online defrag, please post. I'm very interested. delayed allocation this needs to be in the VFS desperately. every new advanced filesystem is winding up implementing their own logic for this... Address spaces (viro) can someone elaborate? sort out interface to block devices (viro) mostly done? -- Jeff Garzik | Only so many songs can be sung Building 1024 | with two lips, two lungs, and MandrakeSoft, Inc. | one tongue.
[Fwd: new HFS+ developer technote from Apple]
I am not a heavy-duty programmer, so I can't help much in this regard, but I know that many of us would love (ie, desperately need) HFS+ access from linux. And, it looks like Apple has created a document to help in this regard. I hope this is helpful to somebody out there! http://developer.apple.com/technotes/tn/tn1150.html Description: This Technote describes the on-disk format for an HFS Plus volume. It does not describe any programming interfaces for HFS Plus volumes. This technote is directed at developers who need to work with HFS Plus at a very low level, below the abstraction provided by the File Manager programming interface. This includes developers of disk recovery utilities and programmers implementing HFS Plus support on other platforms. This technote assumes that you have a conceptual understanding of the HFS volume format, as described in Inside Macintosh: Files. Sincerely, Tom Dilling Production Editor, OncoLink http://www.oncolink.upenn.edu/ [EMAIL PROTECTED] ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Re: (reiserfs) Re: RFC: Re: journal ports for 2.3?
On Thu, 23 Dec 1999, Hans Reiser wrote: All I'm going to ask is that if mark_buffer_dirty gets changed again, whoever changes it please let us know this time. The last two times it was changed we weren't informed, and the first time it happened it took a long time to figure it out. Can't you figure this sort of thing out on your own? Generally if you want to stay updated on something, you are the one who needs to do the legwork. And grep'ing patches ain't that hard Jeff
State of VFS threading?
What needs to be done before the big kernel lock can moved in favor of the finer-grained inode lock? Thanks, Jeff -- Jeff Garzik | Just once, I wish we would encounter Building 1024| an alien menace that wasn't immune to MandrakeSoft, Inc. | bullets. -- The Brigadier, "Dr. Who"
Re: Linux Buffer Cache Does Not Support Mirroring
(moved to linux-fsdevel) SGI's XFS white paper[1] describes XFS delays allocation of user data blocks when possible to make blocks more contiguous; holding them in the buffer cache. This allows XFS to make extents large without requiring the user to specify extent size, and without requiring a filesystem reorganizer to fix the extent sizes after the fact. This also reduces the number of writes to disk and extents used for a file. Is this sort of manipulation possible with the existing buffer cache? Regards, Jeff [1] http://www.sgi.com/Technology/xfs-whitepaper.html
Location of shmfs?
Does anyone know where I can find code for shmfs? The author (Eric B.) was sent a request several weeks ago, but no response has been forthcoming. A Google search turned up the URL http://www.npwt.net/~ebiederm/files/ but that URL cannot be accessed. Regards, Jeff
Continuing the procfs cleanup (was Re: updates to procfs?)
Alexander Viro wrote: On Tue, 19 Oct 1999, Jeff Garzik wrote: Comments on your procfs patch: I like it. :) It looks like many xxx_read_proc operation in fs/proc/proc_array.c contains the _exact_ same code for adjusting 'len', 'start', etc. Cleanup should take care of that. Putting that stuff into an inline or plain macro would save a lot of [source] code. But I think proc_array.c can be made even smaller. Maybe 80% of the functions could be condensed into something like: DECLARE_SIMPLE_READ_PROC(filesystems_read_proc, get_filesystem_list) DECLARE_SIMPLE_READ_PROC(dma_read_proc, get_dma_list) Yes, but it's _not_ a good thing. See comment in the beginning of proc_misc.c - the thing you are talking about is the wrapper turning -info-ish stuff into -read_proc one. It's OK for the small things, but for anything large... Look into drivers/pci/proc.c - I did a proper conversion there and IMO the same should be done for the rest of them. Ok, well my main complaint is that there is duplicate code no matter how you scatter or update things. In pci_read_proc there is logic to calculate 'count', 'eof', etc. which is duplicated many times. My idea for solving this is to create struct proc_print, and function proc_printk: int proc_printk (struct proc_print *p, const char *format, ...) 'struct proc_print' would contain all the args passed to xxx_read_proc, and proc_printk would update that information each time it is called. proc_printk can also be set up to handle overflows of the procfs output buffer, multiple output buffers, etc.
Re: Continuing the procfs cleanup
Guest section DW wrote: From: Alexander Viro [EMAIL PROTECTED] There's actually one more TODO point. And pretty serious one, at it. We got a severely cluttered namespace under /proc (little gems a-la /proc/h8 and friends). It's a Bad Thing (tm) for a lot of obvious reasons. We can move to something saner if a) we'll agree on a naming policy b) add a PROC_COMPAT option that would just create a bunch of static symlinks from old to new locations. I think starting a PROC_COMPAT option would be a rather bad idea. In a development series it is permissible to change things, and in a new stable release one may require people to upgrade utilities. Having PROC_COMPAT only complicates things - it will cause problems instead of solving them. Yes, I am beginning to agree with this viewpoint much more Moving things around in /proc is really an issue that needs to be solved on a driver-to-driver basis. Also, some drivers can simply be converted to the new proc_driver_xxx helper, which automatically puts things inside "/proc/drivers" sub-directory.
Re: updates to procfs?
Comments on your procfs patch: I like it. :) It looks like many xxx_read_proc operation in fs/proc/proc_array.c contains the _exact_ same code for adjusting 'len', 'start', etc. Cleanup should take care of that. Putting that stuff into an inline or plain macro would save a lot of [source] code. But I think proc_array.c can be made even smaller. Maybe 80% of the functions could be condensed into something like: DECLARE_SIMPLE_READ_PROC(filesystems_read_proc, get_filesystem_list) DECLARE_SIMPLE_READ_PROC(dma_read_proc, get_dma_list) Still other functions in proc_array look like they can be similarly simplified: DECLARE_READ_PROC(ksyms_read_proc, get_ksyms_list) IMHO it would be even better if proc_array didn't have to exist at all, and the /proc hook would be 100% declared in the module where get_xxx_list() exists. Jeff
Re: inode cache question
Alexander Viro wrote: i_nlink is 0 (at the moment of last iput(), that is). Otherwise it is thrown out only when the memory pressure comes. In any case -clear_inode() is called before releasing the thing. Moreover, there is a Excellent, that's what I'm looking for I am interested in keeping inode data either in the inode cache, OR the backing store, but not both. Details, please. If you are talking about procfs - keep in mind that we may have multiple mounts. shmfs. If data is in the inode cache, then ideally an additional copy should not be in VM... Thanks, Jeff -- Jeff Garzik | Just once, I wish we would encounter Building 1024| an alien menace that wasn't immune to MandrakeSoft, Inc. | bullets. -- The Brigadier, "Dr. Who"
inode cache question
When does an inode enter, and leave the inode cache? (ie. at what VFS entry points) I am interested in keeping inode data either in the inode cache, OR the backing store, but not both. Regards, Jeff -- Jeff Garzik | Just once, I wish we would encounter Building 1024| an alien menace that wasn't immune to MandrakeSoft, Inc. | bullets. -- The Brigadier, "Dr. Who"
