Bug#201191: partconf: mkfs should indicate progress
* Steinar H. Gunderson <[EMAIL PROTECTED]> [2003-11-16 19:17]: | Did we get anywhere on this? I'd vote in favour of rewriting partconf using | libparted for the file system generation, but if people disagree I could | probably write a simple progress bar. (In that case, do we want to try to | grok the mkfs output for a few known filesystems, or not?) If you plan to rewrite partconf using libparted, please include a way to extend partconf with filesystems, which are not supported by libparted. We need an easy way to create own installiers with xfs or jfs included. Maybe you can write a simple progressbar for those filesystems. Bye Thorsten -- Thorsten Sauter <[EMAIL PROTECTED]> (Is there life after /sbin/halt -p?) signature.asc Description: Digital signature
Bug#201191: partconf: mkfs should indicate progress
Did we get anywhere on this? I'd vote in favour of rewriting partconf using libparted for the file system generation, but if people disagree I could probably write a simple progress bar. (In that case, do we want to try to grok the mkfs output for a few known filesystems, or not?) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#201191: partconf: mkfs should indicate progress
On Tue, Nov 11, 2003 at 11:03:53AM +0100, Gaudenz Steinlin wrote: > This depends on the size of the filesystem and if dma is enabled or not. > enabling DMA speeds up filesystem creation a lot on big disks. With DMA > disabled it can take several minutes to create a big filesystem. It can, even with DMA. autopartkit uses at least a few minutes when creating an ext2 filesystem on a 75GB disk (with DMA). > I suggest a simple solution. I think the most important thing is that > users don't see a blue screen for several seconds like it's now, but a > progress bar. I would only step it forward after one filesystem is > created, so we don't have to parse mkfs.* output. A setup with only one > root partition and one swap would have two steps: > 0% creating filesystem on /dev/... > 50% creating swap on /dev/... > 100% finished It would definitely help compared to what we have today, but it would still suck. > I think one point of having partitioner is, that it does not use > libparted for filesystem creation and is therefore more versatile and > less prone to errors. Why would running mkfs.ext2 be more versatile than using libparted? (Like I said, I'd use mkfs.* for JFS etc., but ATM we don't even have that on our install disks. :-) ) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#201191: partconf: mkfs should indicate progress
On Tue, 2003-11-11 at 15:15, Steinar H. Gunderson wrote: > > I suggest a simple solution. I think the most important thing is that > > users don't see a blue screen for several seconds like it's now, but a > > progress bar. I would only step it forward after one filesystem is > > created, so we don't have to parse mkfs.* output. A setup with only one > > root partition and one swap would have two steps: > > 0% creating filesystem on /dev/... > > 50% creating swap on /dev/... > > 100% finished > > It would definitely help compared to what we have today, but it would still > suck. Yes, but I don't think it's worth to invest more time in that now. This would be an easy and acceptable solution. > > > I think one point of having partitioner is, that it does not use > > libparted for filesystem creation and is therefore more versatile and > > less prone to errors. > > Why would running mkfs.ext2 be more versatile than using libparted? (Like I > said, I'd use mkfs.* for JFS etc., but ATM we don't even have that on our > install disks. :-) ) I don't know how stable parted on i386 is. Last time I tried to format a partition with parted on my powerbook it just hung forever and did not format the partition. So I thought parted my be a little bit flaky. Actually I don't know if the bug is in the frontend or the library. Gaudenz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#201191: partconf: mkfs should indicate progress
On Tue, Nov 11, 2003 at 03:30:30PM +0100, Gaudenz Steinlin wrote: >> It would definitely help compared to what we have today, but it would still >> suck. > Yes, but I don't think it's worth to invest more time in that now. This > would be an easy and acceptable solution. Well, it's not a matter of time, really -- adding progress bars to autopartkit was quite easy once libparted1.6 support was in place. It's more a matter of "is this an okay way of doing it". > I don't know how stable parted on i386 is. Last time I tried to format a > partition with parted on my powerbook it just hung forever and did not > format the partition. So I thought parted my be a little bit flaky. > Actually I don't know if the bug is in the frontend or the library. FWIW, I've used autopartkit quite a lot, and never seen any problems with libparted. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#201191: partconf: mkfs should indicate progress
Am Die, den 11.11.2003 schrieb Steinar H. Gunderson um 04:02: > A quick test indicates that most interesting mkfs-variations (ext2, ext3, > reiserfs; vfat and jfs are so quick it doesn't need progress, and xfs seems > only a bit slower than that) has at least some kind of progress output, so we > _could_ theoretically grok that. It will be ugly, though... This depends on the size of the filesystem and if dma is enabled or not. enabling DMA speeds up filesystem creation a lot on big disks. With DMA disabled it can take several minutes to create a big filesystem. I suggest a simple solution. I think the most important thing is that users don't see a blue screen for several seconds like it's now, but a progress bar. I would only step it forward after one filesystem is created, so we don't have to parse mkfs.* output. A setup with only one root partition and one swap would have two steps: 0% creating filesystem on /dev/... 50% creating swap on /dev/... 100% finished > > libparted1.6 supports ext2, ext3, vfat and reiserfs, but no jfs or xfs. One > _could_ use libparted for the first four and fall back to mkfs.* for > everything else; that would be a definitive improvement for 95% of our users > (as I said, jfs and xfs seem fast already). More code that could go wrong, > though... I think one point of having partitioner is, that it does not use libparted for filesystem creation and is therefore more versatile and less prone to errors. > > This should really be fixed for beta 2. :-) ACK. gaudenz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#201191: partconf: mkfs should indicate progress
A quick test indicates that most interesting mkfs-variations (ext2, ext3, reiserfs; vfat and jfs are so quick it doesn't need progress, and xfs seems only a bit slower than that) has at least some kind of progress output, so we _could_ theoretically grok that. It will be ugly, though... libparted1.6 supports ext2, ext3, vfat and reiserfs, but no jfs or xfs. One _could_ use libparted for the first four and fall back to mkfs.* for everything else; that would be a definitive improvement for 95% of our users (as I said, jfs and xfs seem fast already). More code that could go wrong, though... This should really be fixed for beta 2. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#201191: partconf: mkfs should indicate progress
On Tue, Jul 15, 2003 at 08:53:30AM +0200, Petter Reinholdtsen wrote: > [Sebastian Ley] > > I know that will be difficult, but as Tollef stated we need a progress > > indicator for mkfs. If nothing happens when formatting a large partition > > the lowbrow user might believe d-i crashed or something... > > If we use libparted 1.6 for filesystem generation, it should be able > to supply progress information. libparted can only create ext[23], *fat and reiserfs, right? The advantage of the current method is that it's very easy to drop in other file system types, since all partconf does, is cross-check /proc/filesystems and /sbin/mkfs.* /Martin -- Martin Sjögren [EMAIL PROTECTED] Phone: +46 (0)31 7490880 Cell: +46 (0)739 169191 GPG key: http://www.strakt.com/~martin/gpg.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#201191: partconf: mkfs should indicate progress
* Petter Reinholdtsen <[EMAIL PROTECTED]> [2003-07-15 08:53]: | If we use libparted 1.6 for filesystem generation, it should be able | to supply progress information. will labparted support all common filesystems? (eg reiserfs, xfs, jfs, ...) -- Thorsten Sauter <[EMAIL PROTECTED]> (Is there life after /sbin/halt -p?) pgp0.pgp Description: PGP signature
Bug#201191: partconf: mkfs should indicate progress
[Sebastian Ley] > I know that will be difficult, but as Tollef stated we need a progress > indicator for mkfs. If nothing happens when formatting a large partition > the lowbrow user might believe d-i crashed or something... If we use libparted 1.6 for filesystem generation, it should be able to supply progress information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#201191: partconf: mkfs should indicate progress
Package: partconf Version: 0.05 (not installed) Severity: normal I know that will be difficult, but as Tollef stated we need a progress indicator for mkfs. If nothing happens when formatting a large partition the lowbrow user might believe d-i crashed or something... -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux coyote 2.4.20 #1 Fri Jun 13 19:12:09 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
