Date: Wed, 19 Dec 2001 11:45:21 -0800 From: Bakul Shah <bakul@bitblocks.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Andrea Campi <andrea@webcom.it>, freebsd-arch@FreeBSD.ORG, freebsd-fs@freebsd.org Subject: Re: Real world Root Resizing (was Re: Proposed auto-sizing patch ... Message-ID: <200112191945.OAA04975@repulse.cnchost.com> In-Reply-To: Your message of "Wed, 12 Dec 2001 10:36:19 PST." <3C17A3A3.A439BE21@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[sorry, I should have sent my original message to -fs instead of -arch]
Andrea Campi wrote:
> #include <std/disclaimer>
>
> I was able to simple boot to single user and growfs my / without any magic.
> I *might* have changed it to read-only just for safety but I don't think so
You are a smarter person than I! I believed the growfs man
page (it only works on unmounted file system) but should've
realized it would work on a readonly mount provided you
reboot right after. But I admit, I didn't trust growfs to be
bug free which is why I first made a mirror copy of the root
partition.
Terry Lambert writes:
> You could imagine a brute force tool to do this: back up to tape,
> newfs, and restore from tape.
You can tar cf to another filesystem and tar xf for the
special case of a small root filesystem.
> A better tool would allow you to defragment an existing FS, or even
> run in the background at boot, and defragment only if necessary (some
> inequality threshold on per cylinder group fill amounts, perhaps).
>
> An even better tool might allow you to "defragment" a large disk, at
> the same time declaring the end of that disk "off limits". Doing
> that would let you actually free up cylinder groups at the end of a
> disk -- and shrink partitions, as well as expand them.
I wonder if one can devise a syscall interface to do this
safely without requiring detailed knowledge of the FS layout
and replicating a lot of FS code in user mode.
* For shrinking a partition you need a syscall to limit
disk block allocation. Something like
int fs_alloc(const char* mountpoint, size_t offset, size_t limit);
This would do all allocation the [offset..limit) range
until the next call. Even if you grew a file outside this
range, the new blocks will be allocated here. A filesystem
that does not implement this functionality returns ENOSYS.
offset and limit are in disk blocksize unit but may need to
be rounded up to some FS specific parameter (such as
cylinder group size for FFS).
* For defragmenting you need a way to move file data.
Something like
int frealloc(fd, offset, count, addr)
offset & count must be multiples of disk block size.
addr is a hint as to where these blocks should be moved.
The call fails if the suggested new blocks are in use.
The FS code atomically (at syscall level) moves specified
blocks to the new area.
* You also need to be able to get to various freelists.
I can't see how defragmentation can be done without some
knowledge of FS layout but perhaps most of the details can be
abstracted out well enough that the same interface can be
used for different FSes.
You would run this on a quiescent system but there is no need
to unmount the FS or even bring the system down to single
user.
Placement of files can also be changed once you have this
interface. One idea is to sample file access time. Files
that gets read frequently can be moved to reduce seek time.
Files with similar access time can be clustered and so on.
What would be better than sampling atime is keeping read
stats in each inode: each time a file is read and the atime
is to be updated, increment a small counter (but make it
`stick' when it reaches max). This counter is zeroed when
the stats are gathered by a user program. I am not holding
my breath though.
Comments?
-- bakul
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112191945.OAA04975>