On Thu, Aug 04, 2011 at 10:02:10AM -0400, Benjamin Lipton wrote: > On Thu, Aug 4, 2011 at 3:23 AM, Iustin Pop <[email protected]> wrote: > > > On Wed, Aug 03, 2011 at 06:27:21PM -0400, Ben Lipton wrote: > > > The UUID and TYPE don't always come out of blkid in the same order, > > > apparently... > > > > > > Also, since we put everything on the root filesystem on the target, > > > > Hmm, does this mean the original partition structure is lost? > > > > I'm wondering if this shouldn't be configurable; at least for similar > > sized disks, I don't see any immediate reason why we wouldn't keep the > > original structure (or at least plan to do so in a later version). > > > > Agreed, I moved to a single partition mostly for simplicity in the first > version, but keeping the same layout is probably better. In fact, I don't > think it's much harder to use an arbitrary partitioning scheme than to copy > the same partition layout. The main difference is that you need to interact > with the user somehow to define the new layout. > > > > > > we should > > > clean out entries for the other filesystems. The policy is to remove any > > lines > > > that mount a file (like /dev/*) into the filesystem, and are not the root > > FS or > > > the swap partition. > > > > > > Signed-off-by: Ben Lipton <[email protected]> > > > --- > > > Please take note of how this changes the output fstab. I can't decide > > whether > > > deleting those lines is bad. Those particular ones aren't useful in > > Ganeti, but > > > I'm not sure that this policy is actually correct. It leaves things like > > proc > > > intact, but it might still remove too much. Maybe noauto lines should be > > > allowed to stay, even if not useful? Thoughts? > > > > Yes, noauto is fine. default/auto though not, as that will prevent the > > boot. > > > > Since we do a significant change to the partitioning anyway, I wonder if > > it wouldn't make more sense to generate a fresh one instead of modifying > > the original one… > > > > Maybe so. We could generate one with three lines (/, /proc, swap) or, if > there are more partitions, whatever they are. If we keep the old version > around as fstab.old then the user can replace any special other things they > had in there, if they're appropriate. This might even be a job for the > transfer script, which already has this information, rather than a fix > script, which has to deduce it. Should I do that rather than trying to munge > the old file?
Not sure. On one hand, generating a fresh fstab is easier, on the other hand, it might be that there are not-local-disk filesystems (debugfs or nfs or whatever) that should be preserved… Let's keep the current model, with editing of the fstab. I'll review the patch as is. thanks, iustin
