Re: ext2 feature request
[EMAIL PROTECTED] wrote: The answer to that is pretty simple --- you create a compatible filesystem feature, and indicate the number of "extra" saved blocks in the superblock. Old e2fsck's who don't know about the compatible filesystem features will refuse to touch the filesystem, so they won't clear the extra bits in the block bitmap. However, since it's a compatible filesystem feature, the kernel will happily mount such a filesystem --- since it trusts the accuracy of the block allocation bitmaps, it won't try to allocate any of the reserved blocks. Clever. P.S. The e2fsprogs 1.19 will have support for off-line resizing, even without this feature. It just simply moves the inode table if necessary (with very paranoid, very carefully written code). (Yes, that's right, the GPL timeout on resize2fs finally timed out.) If you want an early peek at it, the 1.19 pre-release snapshot at e2fsprogs.sourceforge.net already has it. I just need to get a couple of final bug fixes/enhancements before I release 1.19 for real. (I'm currently debapting whether or not to code this above idea before or after the 1.19 release. :-) So can your ext2 resizer move the start? Can it move it, even if the blocks don't align? Andrew Clausen
Re: ext2 feature request
Guest section DW wrote: Let me partially contradict you. DOS can handle 23 of these partitions. In the above I did not necessarily mean "outer extended" - the "inner extended" also work. Thus, as soon as something lives inside the outer extended partition, that is, as soon as something is a logical partition, one has this possibility of using a starting offset. Ah. I didn't realise this was the case. I thought there was an expectation that you followed particular alignment rules. But indeed, it does not work in general, that is why I said "logical". Sorry, missed it :-) [And this is a theoretical discussion only. It would be rather unwise to actually use this freedom DOS gives you. It would also be rather unwise to invent new freedom for ext2.] I was just thinking, there is a Linux extended partition (0x85). Could we use that? It would probably screw up fdisk, but everyone will be using parted anyway ;-) (Seriously: we could change fdisk) Andrew Clausen
Re: ext2 feature request
Alexander Viro wrote: ... _that_ (offset being not a multiple of block size) would require changes in fs/buffer.c and drivers/block/ll_rw_blk.c and frankly, I don't see the point - extra overhead for everyone, and what for? Hmmm, it does look like it would mess everything up :-( I know this is messy, but: it's probably possible to fake it at the partition table end. I.e., have some magic partition type that has some header, saying where the "real" start of the partition is, etc. Argghh. Forget it. * clausen swears in M$'s general direction Andrew Clausen
Re: ext2 feature request
Guest section DW wrote: This type already exists - it is called extended partition. For each logical partition you can choose the offset yourself. (And never mind cylinder boundaries - geometry is out.) This won't work in general, because DOS expects only one extended partition. We need something that DOS recognises as a single vanilla partition. Andrew Clausen
[Fwd: [linux-audio-dev] info point on linux hdr]
Hi all, Any comments? i mentioned in some remarks to benno how important i thought it was to preallocate the files used for hard disk recording under linux. i was doing more work on ardour yesterday, and had the occasion to create some new "tapes", of lengths from 2 to 40 minutes. the simple act of creating 24 5 minute WAV files on ext2, files in which every block has been allocated, takes at least 1 minute, perhaps as much as 2. i create the files by first opening them, then writing a zero byte every blocksize bytes (blocksize comes from stat(2)), except for the WAV header at the beginning. i hadn't done this in a while, but it reminded me of the near-impossibility of expecting the FS code to allocate this much disk space in real time under ext2. If someone knows of a faster way to allocate the disk space, please let me know. Its not that I have a problem right now, just wanted to point out this behaviour. --p
Re: /proc/mounts, /dev/root
"Patrick J. LoPresti" wrote: Try "cat /proc/sys/kernel/real-root-dev". Convert to hex and maybe you will see something familiar. Or maybe not :-). This is exactly what I need! Thanks! Andrew Clausen
Re: /proc/mounts, /dev/root
Tigran Aivazian wrote: if rdev is not there you copy it using cp(1) command. I didn't explain myself very well. Sorry. I'll try again... I'm writing partition program, that needs to find out if a partition is mounted. Sometimes, /etc/mtab is not available (eg / is mounted read-only). Therefore, I should check /proc/mounts first, if it's available. But /proc/mounts has this /dev/root brain damage. So I need to find out what /dev/root really is. I want to allow users to use Parted with chroot, because this could be useful in a rescue situation. Obviously, I can't force/recommend users use devfs. Also, Parted will be run *after* any chroot, so copying rdev is out of the question. Anyone have any other suggestions? Thanks, Andrew Clausen
Re: /proc/mounts, /dev/root
Tigran Aivazian wrote: even if you chroot somewhere, rdev will still show the correct root: What if rdev isn't on the chroot'ed root? Also, does rdev need find the kernel image, or does it ask the kernel? Thanks! Andrew Clausen
Re: /proc/mounts, /dev/root
Tim Waugh wrote: On Fri, 17 Mar 2000, Andrew Clausen wrote: stat / Doesn't work with chroot :-( Can you mount proc? stat /proc/1/cwd..? Permission denied (even as root), for obvious reasons. Andrew Clausen
