Why use Ext 3 and not Ext 4 format?
Why use Ext 3 and not Ext 4 format?
I am not totally convinced that ext 4 is totally bug free.
Ext 4 bug report.
https://bugzilla.kernel.org/buglist.cgi ... e%20System
Bug report for ext 3
https://bugzilla.kernel.org/buglist.cgi ... e%20System
Ext 3 - 7 bugs.
Ext4 - 81 bugs.
Ext 4 bug report.
https://bugzilla.kernel.org/buglist.cgi ... e%20System
Bug report for ext 3
https://bugzilla.kernel.org/buglist.cgi ... e%20System
Ext 3 - 7 bugs.
Ext4 - 81 bugs.
Last edited by bigpup on Wed 19 Dec 2018, 12:29, edited 1 time in total.
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
Gotta say here that since switching to exclusive Ext4 I have not had a fail. I was always getting lost nodes in ext2.
I picked a random issue and looked at that. https://bugzilla.kernel.org/show_bug.cgi?id=194567 and it appeared to be related to a huge file system of a size I would never get near.
So I'd suggest you would need to analyse each issue to see what the real problems turn out to be , but I;ll leave that to you bigpup .
I picked a random issue and looked at that. https://bugzilla.kernel.org/show_bug.cgi?id=194567 and it appeared to be related to a huge file system of a size I would never get near.
So I'd suggest you would need to analyse each issue to see what the real problems turn out to be , but I;ll leave that to you bigpup .
https://www.thegeekstuff.com/2011/05/ext2-ext3-ext4/
For those of us who occasionally explore older Puppies --and especially those who can only use them-- Puppies whose kernel's predate 2.6.19 can't be run from a Linux Ext4 partition.
I don't have a drive larger than 32 Terabytes, the limit which Linux Ext 3 can handle.
Although I didn't find any information about it --I didn't do an exhaustive search-- I have a sneaking suspicion that in order to control more hardware Linux Ext4 will use more hard-drive space and more computing resources (CPU and RAM) for itself than Ext3. It might not be much. But unless I have a need to control over 32 Terabytes, why take the chance of 'wasting' the computing resources I do have?
mikesLr
For those of us who occasionally explore older Puppies --and especially those who can only use them-- Puppies whose kernel's predate 2.6.19 can't be run from a Linux Ext4 partition.
I don't have a drive larger than 32 Terabytes, the limit which Linux Ext 3 can handle.
Although I didn't find any information about it --I didn't do an exhaustive search-- I have a sneaking suspicion that in order to control more hardware Linux Ext4 will use more hard-drive space and more computing resources (CPU and RAM) for itself than Ext3. It might not be much. But unless I have a need to control over 32 Terabytes, why take the chance of 'wasting' the computing resources I do have?
mikesLr
The biggest thing bad about ext 2 is it can get corrupted over time or is easier to corrupt.musher0 wrote:Well... why use ext3 when you can use ext2? It leaves more room on the partition.
However, if you have the pfix=fsck as an option in the boot menu entry kernel line. That seems to fix the corruption problem.
It does a file system check each time you boot and corrects any errors it finds.
Code: Select all
kernel /xenialpup6475uefi/vmlinuz psubdir=xenialpup6475uefi pmedia=atahd pfix=fsck
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
In using Quirky, I use vfat and f2fs as the defaults. I've had very little issue with either; though I usually don't keep them around more than a year before overwriting with a new version of things.
I never really had a problem with ext2 and never used ext 3 or ext 4. As Mike stated and as I also recall, the ext3 and ext4 were not working in some of the earlier puppies I tried; so I basically took them off of my to use list.
I never really had a problem with ext2 and never used ext 3 or ext 4. As Mike stated and as I also recall, the ext3 and ext4 were not working in some of the earlier puppies I tried; so I basically took them off of my to use list.
ntfs - in case anyone needs 2 know
How I overlooked such fundamental basics for DECADES is shamefully embarassing. In your exploration of bugs vs. benefit I did note "ntfs missing"
How in 30 entire years of this, had I not noticed so much as a "HOAX" (anyone recall the y2k bug?) about an ntfs bug... What the STFU
Should anyone have curiosity about ntfs, or anything m$ related for that matter.
To my (almost regrettable) knowlege, there exist ONLY TWO (if there are more, please fill me in. MSDN or m$ do NOT pass my integrity check) trustworthy sources: Leo and GRC.
Check BOTH, compare, contrast. Neither takes precedence. More information's all over the place, useful to varying degrees. If you feel uncertain and need to use something you've discovered elsewhere, first look it up @ both of those places above.
Recent personal experience indicates ntfs to be downright fragile compared to ext4.
2 seperate, 300 gig drives, both over 2 years old, each partitioned like so:
/dev/sda1 == arch (ext4) 50G
/dev/sda2 == ST0 (ntfs) 200G
/dev/sda3 == stuf (ext4) 32G
/dev/sda4 == SWAP 6G
both in the same 3Ghz CPU, 4Gig RAM box.
on BOTH aging drives, the ntfs started failing first.
Locally archived files won't open. Jpgs scrambling, pdfs ditto -- the usual.
Scrambled like a cat on a hot tin roof to get everything off the first "failing ntfs" I found maybe 75% survived of almost full 200 gig .
The 2nd drive was added in haste -- faced with 25% data loss, QUICK! Get my system onto something ELSE! (ooooops)
With little effort I'd cloned everything off the ext4 partitions onto the "new drive" and was running right along, no problem, other than a bit noisy for my liking....
note: NOTHING was lost from the ext4 partions
Ya get one guess which one ultimately and utterly failed. The only indication before said failure was the exact same "hinky" file scrambling on the (cough) "new" /dev/sda2=ntfs....
Leading me to discover the Distro I'd been running had been "upgraded" (where's the "tag" for AIRQU0TES?) And now your puppy's trying to teach old elder-tard here when it "wants out"
In spite of elder-n00b, with puppy on the thumb drive, about 80% of the data from the ext4 partitions was retieved before the 5th "freezer trick" failed.
80% of >= 60 Gigs. Had the bearings held up I'd wager it would have been even more. "ALL" = impossible. When the MBR evaporates and none of the usual measures can bring it back, I was surprised to get ANY...
How it was the file table survived the attempts to revive the MBR escapes me. I'm guessing this means I should more fully acquaint my self with "journaling".
How in 30 entire years of this, had I not noticed so much as a "HOAX" (anyone recall the y2k bug?) about an ntfs bug... What the STFU
Should anyone have curiosity about ntfs, or anything m$ related for that matter.
To my (almost regrettable) knowlege, there exist ONLY TWO (if there are more, please fill me in. MSDN or m$ do NOT pass my integrity check) trustworthy sources: Leo and GRC.
Check BOTH, compare, contrast. Neither takes precedence. More information's all over the place, useful to varying degrees. If you feel uncertain and need to use something you've discovered elsewhere, first look it up @ both of those places above.
Recent personal experience indicates ntfs to be downright fragile compared to ext4.
2 seperate, 300 gig drives, both over 2 years old, each partitioned like so:
/dev/sda1 == arch (ext4) 50G
/dev/sda2 == ST0 (ntfs) 200G
/dev/sda3 == stuf (ext4) 32G
/dev/sda4 == SWAP 6G
both in the same 3Ghz CPU, 4Gig RAM box.
on BOTH aging drives, the ntfs started failing first.
Locally archived files won't open. Jpgs scrambling, pdfs ditto -- the usual.
Scrambled like a cat on a hot tin roof to get everything off the first "failing ntfs" I found maybe 75% survived of almost full 200 gig .
The 2nd drive was added in haste -- faced with 25% data loss, QUICK! Get my system onto something ELSE! (ooooops)
With little effort I'd cloned everything off the ext4 partitions onto the "new drive" and was running right along, no problem, other than a bit noisy for my liking....
note: NOTHING was lost from the ext4 partions
Ya get one guess which one ultimately and utterly failed. The only indication before said failure was the exact same "hinky" file scrambling on the (cough) "new" /dev/sda2=ntfs....
Leading me to discover the Distro I'd been running had been "upgraded" (where's the "tag" for AIRQU0TES?) And now your puppy's trying to teach old elder-tard here when it "wants out"
In spite of elder-n00b, with puppy on the thumb drive, about 80% of the data from the ext4 partitions was retieved before the 5th "freezer trick" failed.
80% of >= 60 Gigs. Had the bearings held up I'd wager it would have been even more. "ALL" = impossible. When the MBR evaporates and none of the usual measures can bring it back, I was surprised to get ANY...
How it was the file table survived the attempts to revive the MBR escapes me. I'm guessing this means I should more fully acquaint my self with "journaling".
- Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
@slowride:-
Since moving to Pup, a few years ago, I quickly discovered (like so many others before me), that ext3 just seems to 'work' better with Pup than ext4. Don't ask me why, but personal experience has indicated this to be the case.
Since switching to ext3, and always running the "pfix=fsck" kernel-line parameter, I've not had one single 'fail'.
Mike.
This is why you'll never catch me using ext2. No journalling.....which makes file-corruption recovery so much easier.slowride wrote:How it was the file table survived the attempts to revive the MBR escapes me. I'm guessing this means I should more fully acquaint my self with "journaling".
Since moving to Pup, a few years ago, I quickly discovered (like so many others before me), that ext3 just seems to 'work' better with Pup than ext4. Don't ask me why, but personal experience has indicated this to be the case.
Since switching to ext3, and always running the "pfix=fsck" kernel-line parameter, I've not had one single 'fail'.
Mike.
May I just point out that the Y2K bug was NOT a hoax.
There were an awful lot of people that spent an awful lot of time going through code and fixing it so that it would NOT happen.
I know that I must have checked a couple of thousand programs, and I wasn't the only one in that company doing so.
The fact that there wasn't a huge problem is one of the biggest success stories of the computing industry.
There were an awful lot of people that spent an awful lot of time going through code and fixing it so that it would NOT happen.
I know that I must have checked a couple of thousand programs, and I wasn't the only one in that company doing so.
The fact that there wasn't a huge problem is one of the biggest success stories of the computing industry.
"Just think of it as leaving early to avoid the rush" - T Pratchett
My bad
Noted, and thank you.Burn_IT wrote:May I just point out that the Y2K bug was NOT a hoax.
PM is welcome, email now works (REPLIES might be slow, health limits console time)
[color=green][i][b]Anonymity is the Spiritual Foundation of all our Principles; ever reminding us to place Princicples before Personalities[/b][/i][/color]
[color=green][i][b]Anonymity is the Spiritual Foundation of all our Principles; ever reminding us to place Princicples before Personalities[/b][/i][/color]
My tests
Did 3 tests - formatted a 60gb partition as ext2, ext3, ext4. Between each format, I untar-ed a folder with 4 large & about 100 small files (1.2gb), unmounted, then ran fsck -f. Results:- ext2 0.1% non-contiguous; ext3 22.7%, ext4 0.4%. Don't fancy ext3 on that basis.
Did you change the format in this order?formatted a 60gb partition as ext2, ext3, ext4.
This seems like a very high reading for a fresh format.non-contiguous; ext3 22.7%
No logical reason to do that much non-contiguous file placement if there is nothing already on the partition.
I have never seen a reading that high with ext3.
Here is my test results on a fresh format ext3 partition.
Code: Select all
/dev/sdd2: 475/321280 files (0.6% non-contiguous), 886354/1283840 blocks
A little more details:
Code: Select all
3 non-contiguous files (0.6%)
450 regular files
16 directories
Code: Select all
e2fsck -f -y -v -C 0
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
@BigPup - Actually 1000 files (typo). Partiton deleted & recreated via Gparted for each test, including original. Could be a fsck version issue. Last test was from Slacko64-6999. Have retested with BigPup's suggested command, but from LxPupSc64 - 22.7% - 614 non-contig files in both ext2 & ext3. Ext4 - 0.4% in 12 files.
What device is this partition on?
I am getting reports at much less readings than those for ext 3 on a usb hard drive and a usb flash drive.
I am using Xenialpup64 7.5
e2fsck 1.42.13 (17-May-2015)
GParted 0.25.0
I am getting reports at much less readings than those for ext 3 on a usb hard drive and a usb flash drive.
I am using Xenialpup64 7.5
e2fsck 1.42.13 (17-May-2015)
GParted 0.25.0
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)
When I was a kid I wanted to be older.... This is not what I expected
YaPI(any iso installer)