From Fedora Project Wiki
mNo edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
* [[User:Bruno]]: The part limits don't actually guaranty that the resulting image (iso or squashfs) will be a desired size. It will depend on the amount of compression you get. Using larger values will slow down a build at least somewhat, so we don't want them to be way larger than needed. | * [[User:Bruno]]: The part limits don't actually guaranty that the resulting image (iso or squashfs) will be a desired size. It will depend on the amount of compression you get. Using larger values will slow down a build at least somewhat, so we don't want them to be way larger than needed. | ||
** [[User:Kanarip|Jeroen van Meeuwen]]: You're right, it doesn't. Because of this compression however, we need some way to prevent the compose from ending up oversized. These two sizes very roughly indicate where that magic boundary is. Of course if you fill 8192MB with a lot of plaintext files you're gonna end up with a smaller squashfs then when you fill it with a few large binaries. | ** [[User:Kanarip|Jeroen van Meeuwen]]: You're right, it doesn't. Because of this compression however, we need some way to prevent the compose from ending up oversized. These two sizes very roughly indicate where that magic boundary is. Of course if you fill 8192MB with a lot of plaintext files you're gonna end up with a smaller squashfs then when you fill it with a few large binaries. | ||
** [[User:Bruno]]: I guess I am thinking the wording of the why those limits are recommended seems misleading. | |||
** [[User:Bruno]]: And related to compression, lzma is going to eventually result in better (10-20%ish if I remember correctly) compression and may cause us to reevaluate those numbers. | |||
** [[User:Bruno]]: If the performance hit isn't too large, I think recommending one size of say 12288, would simplify things for people making spin kickstarts. The 4 GiB should be checked at the end. Possibly livecd-creator should emit a warning if the resulting iso is over 4 GiB. | |||
* [[User:Bruno]]: On the 4 GiB limit, I received some feedback that modern Windows systems (XP and later) can use NTFS which doesn't have the 4 GiB file restriction. And that it was not expected that a lot of people would want to store the iso images on USB flash drives which commonly use vfat. How true that is in practice, I don't know. | |||
Revision as of 16:01, 17 January 2009
- User:Bruno: The part limits don't actually guaranty that the resulting image (iso or squashfs) will be a desired size. It will depend on the amount of compression you get. Using larger values will slow down a build at least somewhat, so we don't want them to be way larger than needed.
- Jeroen van Meeuwen: You're right, it doesn't. Because of this compression however, we need some way to prevent the compose from ending up oversized. These two sizes very roughly indicate where that magic boundary is. Of course if you fill 8192MB with a lot of plaintext files you're gonna end up with a smaller squashfs then when you fill it with a few large binaries.
- User:Bruno: I guess I am thinking the wording of the why those limits are recommended seems misleading.
- User:Bruno: And related to compression, lzma is going to eventually result in better (10-20%ish if I remember correctly) compression and may cause us to reevaluate those numbers.
- User:Bruno: If the performance hit isn't too large, I think recommending one size of say 12288, would simplify things for people making spin kickstarts. The 4 GiB should be checked at the end. Possibly livecd-creator should emit a warning if the resulting iso is over 4 GiB.
- User:Bruno: On the 4 GiB limit, I received some feedback that modern Windows systems (XP and later) can use NTFS which doesn't have the 4 GiB file restriction. And that it was not expected that a lot of people would want to store the iso images on USB flash drives which commonly use vfat. How true that is in practice, I don't know.