Date: Thu, 15 Aug 2002 10:21:17 -0700 (PDT) From: Patrick Thomas <root@utility.clubscholarship.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: "Daniel O'Connor" <doconnor@gsoft.com.au>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: possible to expand a file for vn-device FS usage ? Message-ID: <20020815102056.J58763-100000@utility.clubscholarship.com> In-Reply-To: <3D5B5BB7.BC424E72@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
What is the negative effect of this fragmentation, and does it mean I won't be able to use all of the space that I added ? On Thu, 15 Aug 2002, Terry Lambert wrote: > Daniel O'Connor wrote: > > On Thu, 2002-08-15 at 17:04, Patrick Thomas wrote: > > > Any suggestions on how to expand that file without doing the dump/restore > > > steps ? > > > > man 8 growfs perchance? :) > > You can unmount it, grow the underlying file with: > > dd if-/dev/zero bs=XXX,count=XXX >> filename > > and *THEN* use growfs(8) on it. > > Doing this will leave the allocation layout in the same state > that it is at present, so the bottom half of the FS will end > up fragmented, even though there is free space at the top (FS > growing does not equally redistribute the FS content into the > newly enlarged space). > > The best approach is the same as it would be for a device: > dump and restore the FS from the old image to the new. In > the vn device case, you could just create a new empty FS of > the necessary size, and dump from the old piped to a restore > of the new. > > If you can live with the internal fragmentation, use growfs(8); > if you can't, use dump/restore. IMO, you will have less > potential for future problems if you use dump/restore. > > -- Terry > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020815102056.J58763-100000>