[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ext2fs resize?



When Waye-Ian CHIEW wrote, I replied:

A utility to pack the current content of a filesystem to one
end (or the other, or the center) of its space would be possible
for each filesystem type, but a general tool would be extremely
difficult (probably impossible).  For example, the original
UNIX file system had all i-nodes at the beginning of the slice
and allocated content blocks as near as possible to the i-nodes,
the Berkely file-system, on the other hand, scatters sets of
i-nodes accross the file-system space, and I suspect that the
linux filesystems have other differences in detail - and we
haven't even considered MSDOS, W$95 (which has at least two
flavors), OS/2, etc.  I have a spare ~400 Mb disk that I use
in conjunction with cpio and gzip to handlew these situations.
A spare HD is probably the best $100 you'll ever spend.

> 
> Hello!
> 
>    > I'm presently trying to shuffle and resize several partitions on a disk device
>    > without losing data.
> 
>    My answer to this is NOT authoritative, that is, I haven't looked
>    at the code. However, in general, partitioning doesn't move data
>    about; it merely updates a small file which delineates the sets
>    of diskblocks that comprise each partition.
> 
>    The filesystem lays
>    out the the blocks of its partition in accordance with it's policy
>    - the filesystem on /proc is very different to those on /usr, or
>    /, or /var which are in turn very different from that on /msdos.
>    The *nix data partitions (/, /usr, /var, etc.) are layed out with
>    a set of i-nodes at the beginning of the partition (or sets of
>    i-nodes scattered throughout) each of which point to the individual
>    blocks (or sets of blocks) which hold the file. The policy (or
>    format) for msdos is very different, and unknown to me, as are
>    the formats of /proc, etc.
> 
> Yes -- and I'm looking for filesystem-specific tools that will shrink an ext2fs
> and a vfat partition.
> 
> But wouldn't resizing be simple to do in principle?  (Defragment the filesystem and
> move everything to the front of the partition, then change the total number of
> blocks in the superblock?)
> 
>    > Can the ext2fs resize itself?
>    > That is, can the filesystem shrink or grow in size to accommondate a resized
>    > partition?  Is there a tool to do this?
>    >
>    > Can the ext2fs move itself?
>    > If the whole filesystem is moved up or down (relative to the start of the
>    > partition), will it still work?
> 
>    Thus partitions aren't easily moved or combined without foreknowledge of the
>    format of the content. Thus, you need to backup each of the partitions
>    involved, re-partition, and restore the backups to the now empty, new,
>    partitions. HTH.
> 
> Unfortunately, the problem over here is that backup isn't really feasible.
> (It's also, theoretically, a very redundant operation.)
> 
> And wouldn't _moving_ also be simple to do in principle?  (Make all filesystem
> references to disk blocks relative to the superblock, not the start of the
> disk.)
> 
> -- Ian!!
> Pobody's nerfect!
> 
> --
> To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-- 
-----------------------------------------
Ralph Winslow		      rjw@nac.net
Mary bought a pair of skates
upon the ice to frisk
now wasn't that a crazy way
her sweet young *?


--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: