Closed yucolabjames closed 5 years ago
That's because you are creating a very large persistent partition, and ext3
"quick" format is very different from Windows FAT32 or NTFS quick format, because it still needs to create a lot of inodes as well as the journal.
We are literally using the exact same library (from e2fsprogs) as the one being natively used by Linux for formatting drives to ext2
or ext3
. It's really the exact same code. However, formatting on Windows is much slower because the I/O code for low level access on Windows (which, again, we take from the official library, since it has some Windows support — we didn't invent our own thing here) is either not as optimized as it is for Linux or (more likely) because the Linux kernel has been actively tailored to speed up native file system I/O access, whereas, of course, the Windows kernel hasn't.
I understand that this is frustrating (I am frustrated about it too!), but I want to make it clear that:
ext2
/ext3
formatting code here. Instead we went out of our way to use the same code as the one being used natively by Linux. So the optimization (or lack of it) and speed difference is really not something that comes from us.ext2
/ext3
formatting code could be better optimized for Windows. If you or anyone else is annoyed with this, I will kindly ask that you work with the e2fsprogs projects and send patches there that can improve Windows performance.Also on a side note, ubuntu-19.04-desktop-amd64.iso still faces the Ubuntu bug 1489855.
Nobody ever said otherwise. In every communication about the subject you've seen from me, I made it exceedingly clear that the only versions of Ubuntu I know of where bug 1489855 has been fixed are the post 2019.07.24 daily-live 19.10 releases. Again, if you are unhappy about the situation, and would like the fix applied to the next 19.04 or 18.04 refresh, please let the relevant people (the Ubuntu distro maintainers) know.
I will now close this issue.
Woops, am not upset about this.
I did read the FAQ, which says persistence will only work if you use Ubuntu 18.10 or later.
I assumed 19.04 would be newer than the said 18.10, yes I wasn't sure how Ubuntu versioning works until this very moment.
If I offended anyone, my apology. Am really appreciative of your effort here. Thanks for the making such a great software!
Ah, shoot, that's a typo in the FAQ. Corrected. The ChangeLog and every other place had the correct 19.10 version.
I hope you dont mind a "discussion"-type question on a closed issue. Background: I tried ext3-formatting a 122GB-sized partition on a USB 2.0 drive and regretted it profusely, which led me to this (and other) issues.
My question is: is there any other filesystem that fulfills the criteria for this? I'm assuming the criteria are:
and regretted it profusely
Can you explain why? I'm afraid it's not exactly clear where you're coming from with your request. Is it the time it took you to format the drive? Is it something else? How long did it take to format your drive?
is there any other filesystem that fulfills the criteria for this?
As far as I know, it has to be ext2
, ext3
or ext4
. I'm not aware of persistence using anything else but ext
, since that is the main Linux file system, and therefore the only one that is guaranteed to be supported out of the box.
However, you may be able to shave some time by forcing ext2
over ext3
, since a journal will not be created then. You can do so by editing the registry and creating a new DWORD key named UseExtVersion
under HKEY_CURRENT_USER\Software\Akeo Consulting\Rufus
and setting its value to 2
. This should about halve the time it takes to format a drive.
For the record, I had a quick look at what e2fsprogs does that is much slower on Windows than on Linux, but it just looks like the file system was never designed with Windows I/O operations in mind, as my understanding is that it needs to write small amounts of data all over place (as opposed to FAT32 or even NTFS, that just seem to need to write a few master blocks here and there), which is inherently slow on Windows, especially when working with a USB 2.0 drive.
Maybe I'll take another look to see if anything can be done to speed up things (because it is likely that the e2fsprogs folks concentrated a lot more on Linux optimization than they did on Windows), but I can't promise anything...
and regretted it profusely
Can you explain why? I'm afraid it's not exactly clear where you're coming from with your request. Is it the time it took you to format the drive? Is it something else? How long did it take to format your drive?
I cancelled about 1-1.5hours into it at around 10% for about 120GB in the partition. It's not the fastest drive either, cheap 128GB USB2.0. I just wasn't expecting this behaviour, I didn't know ext2/3 need to prealloc the inodes -- I was wrongly assuming it'd be similar to FAT32 or NTFS.
is there any other filesystem that fulfills the criteria for this?
As far as I know, it has to be
ext2
,ext3
orext4
. I'm not aware of persistence using anything else butext
, since that is the main Linux file system, and therefore the only one that is guaranteed to be supported out of the box.However, you may be able to shave some time by forcing
ext2
overext3
, since a journal will not be created then. You can do so by editing the registry and creating a new DWORD key namedUseExtVersion
underHKEY_CURRENT_USER\Software\Akeo Consulting\Rufus
and setting its value to2
. This should about halve the time it takes to format a drive.
I have a feeling that the performance issue is due to the static allocation of inodes in the ext filesystems (combined with a slow library and/or a large drive), rather than the journal... When I get around to it, I will test it out.
For the record, I had a quick look at what e2fsprogs does that is much slower on Windows than on Linux, but it just looks like the file system was never designed with Windows I/O operations in mind, as my understanding is that it needs to write small amounts of data all over place (as opposed to FAT32 or even NTFS, that just seem to need to write a few master blocks here and there), which is inherently slow on Windows, especially when working with a USB 2.0 drive.
Maybe I'll take another look to see if anything can be done to speed up things (because it is likely that the e2fsprogs folks concentrated a lot more on Linux optimization than they did on Windows), but I can't promise anything...
Thanks for your efforts!
Would it technically be feasible to have the partition be formated by ubuntu on first startup by installing some init/systemd script that checks for the status of the casper-rw partition? If yes, this would probably be the largest improvement in performance -- but, the first Ubuntu startup would then be delayed for some amount of time -- something you could possibly warn the user about while creating the live usb.
Would it technically be feasible
Not really, because you'd have to recreate initrd which requires having a read-only extfs driver (which we don't have - we just have write support) and even if you do, is a complex and super time consuming operation to carry out. Plus you'd have to hope that the Ubuntu people don't change their init sequence (which they'll do).
There's no way I'm going to look into that, especially when the issue, really, is that you are using a 120 GB drive at USB 2.0 speeds, which is going to be slow no matter what.
Please do yourself a favour and invest on a USB 3.0 drive with write speeds that are at least 60 MB/s (and that is write speed, NOT read speed). Anything less, and you're going to be clutching at straws hoping for a miracle that'll never come.
It may sound harsh but nobody's going to invest time, and a lot of it at that, just to help you save a few precious bucks because you wanted to go for cheap (and therefore slow) hardware... If you don't want to have to wait hours to get your drive formatted, get a faster one!
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.
Checklist
<FULL LOG>
below.Rufus version: x.y.z
- I have NOT removed any part of it.Additionally (if applicable):
(✓)
button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.Issue description
It's more of an observation, it looks like quick format isn't as fast as it could be when creating persistent drives. It's taking 43 mins to format a 128GB drive. Am cool with it if it's working as intended :)
Also on a side note,
ubuntu-19.04-desktop-amd64.iso
still faces the Ubuntu bug 1489855.Log