Do I use ext4 for all partitions (such as / and /boot)? What are the other formats used for?
I'm installing ubuntu onto a new laptop with 24gb SSD and a 500gb HDD. I wanted to put / and swap onto the SSD and /home onto the HDD. Is there anything I shouldn't use ext4 for?
I do not ever intend to dual boot. Ubuntu only.
12.04 installation partitioning ssd ext4
add a comment |
I'm installing ubuntu onto a new laptop with 24gb SSD and a 500gb HDD. I wanted to put / and swap onto the SSD and /home onto the HDD. Is there anything I shouldn't use ext4 for?
I do not ever intend to dual boot. Ubuntu only.
12.04 installation partitioning ssd ext4
add a comment |
I'm installing ubuntu onto a new laptop with 24gb SSD and a 500gb HDD. I wanted to put / and swap onto the SSD and /home onto the HDD. Is there anything I shouldn't use ext4 for?
I do not ever intend to dual boot. Ubuntu only.
12.04 installation partitioning ssd ext4
I'm installing ubuntu onto a new laptop with 24gb SSD and a 500gb HDD. I wanted to put / and swap onto the SSD and /home onto the HDD. Is there anything I shouldn't use ext4 for?
I do not ever intend to dual boot. Ubuntu only.
12.04 installation partitioning ssd ext4
12.04 installation partitioning ssd ext4
asked Aug 25 '13 at 20:06
user187248user187248
31112
31112
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
Swap space doesn't use a filesystem at all. For regular filesystem partitions, my thoughts are:
Ext2fs -- This is the major surviving non-journaled Linux-native filesystem, and as such it has limited utility. I'd only recommend it on a small partition (such as a separate/boot
partition or possibly a small USB flash drive), where the journal will be more of a detriment than an advantage.
Ext3fs -- This is ext2fs plus a journal, which reduces disk-check times after a power failure or system crash. Ext3fs used to be a decent choice, but it's been pretty well eclipsed by ext4fs these days....
Ext4fs -- This is ext3fs plus some new features that improve performance and enable use on larger disks. It's probably the best general-purpose filesystem for Linux these days; certainly it's the one that most distributions favor by default.
ReiserFS -- This filesystem is roughly comparable to ext3fs in features. Its main standout point is that it's especially good at handling small files (as in a few kilobytes, or even under a kilobyte). If you happen to be storing lots of dinky files, it's still worth considering. OTOH, it's not a "hot" filesystem, so development is slow, and ReiserFS lacks the advanced features found in ext4fs and the later filesystems on this list. A variant, Reiser4, promises such features but has been very slow in materializing as an actual in-kernel filesystem. I'm not holding my breath on Reiser4 becoming viable.
XFS -- Favored by system administrators on big disks (over a few terabytes), XFS has some moderately advanced features, and has a good reputation for handling large files. XFS partitions can't be shrunk, though, which can be a problem if you're not sure how big to make your partitions.
JFS -- Similar in many ways to XFS, JFS has never been as popular. A few years ago, it wasn't as reliable, but I'm not sure that's the case any more. I can't think of any good reasons to favor it today on a Linux-only system, although there may be some specialized cases where it would perform better than other filesystems.
Btrfs -- This is the newest Linux-native filesystem, and it includes advanced features like the ability to span a filesystem across multiple disks and to take snapshots. It's still experimental, though, so it's not really recommended for use in production environments.
ph0t0nix mentioned ZFS, but that's not really Linux-native. (It was developed by Sun, and has been ported to some of the BSDs, but licensing issues prevent moving that code into the Linux kernel.) There are two ZFS implementations for Linux, one of which can be built into the kernel and the other of which is a userspace driver accessed via FUSE. The kernel ZFS driver isn't part of the standard Linux kernel, though, which is a big drawback in my view; IMHO, a driver for your main filesystem should be a standard part of the kernel, not an add-on package that might not work if you upgrade your kernel.
Overall, then, and IMHO, the best general-purpose options at the moment are ext4fs and XFS. Of the two, I give the nod to ext4fs because it's more popular and it can be shrunk. Ext2fs is OK on small partitions (say, under 1GB or so), ReiserFS can be good if you store lots of very small files, and Btrfs is good if you need advanced bleeding-edge features and don't mind the risk. I don't happen to have benchmark data handy on these filesystems, and such data can be difficult to interpret because so many factors can influence performance (disk type, file sizes, system load, etc.). You could try looking up such data if speed or system load is particularly important to you.
There are of course non-native filesystems, too -- NTFS, FAT, HFS+, etc. You can't use these as the filesystem for your main Linux installation. (I suppose you might be able to use HFS+ for that purpose, but I've never tried it, and it certainly isn't supported by the Ubuntu installer!) You'd use these for interoperability on dual-boot computers or on removable disks.
While ext3 is indeed ext2 with a journal duct taped to it, I'd say that ext4 isn't really ext3 with extra features. It's a completely rewritten filesystem with totally new features and a journal integrated from the ground up. As for the use-case of JFS, the main reason it might be used is its extremely low resource requirements and its variable-sized filesystem blocks. Other than that, its performance is not ideal (in particular due to the lack of allocate-on-flush/delayed-allocation). Finally, for/boot
, why not just use ext4 with the journal disabled?
– forest
2 days ago
add a comment |
For the setup you propose ext4 is recommended.
If you were to put /boot
as a separate partition, you could use ext2 for that. For large filesystems (e.g. > 16TB I generally use xfs, as it I had some problems with ext4 there (problems when resizing the partition). And btrfs is still not recommended for production. For a server you could consider ZFS, which has been declared stable on Linux a few months ago.
Grub2 don't need to be ext2. Only Grub1 does.
– Braiam
Aug 25 '13 at 22:37
Even GRUB 1 (aka GRUB Legacy) can boot from most Linux filesystems. (I'm not sure about Btrfs, offhand.) The advantage of ext2fs on a small partition is that there's no journal file to consume disk space; on a small partition, the journal file can consume a significant amount of disk space, and the advantages of journaling on a small partition are minimal.
– Rod Smith
Aug 26 '13 at 2:53
@ph0t0nix Large Files System or do you mean large Files? XFS is a good file system when you using as a media center or DVR holding video where files are generally large.
– AngryWombat
Aug 26 '13 at 3:28
1
@AngryWombat: I mean both. At work I manage a couple of filesystems that are large (up to 24TB per filesystem at the moment), some of which contain files of several GB in size (mostly < 10GB, though).
– ph0t0nix
Aug 26 '13 at 7:08
@Ho0t0nix , nice one (have a 1up), I keep that in mind next time... I got do some home work of my own in regards to BtrFS and ZFS working with large file systems. I love the idea behind thesse two FS and what they can do.
– AngryWombat
Sep 1 '13 at 23:53
add a comment |
Use ext4 or XFS for your main partition. Use ext2 or non-journaled ext4 for boot.
You should use ext4 for your main partition. It provides high-performance, is quite stable, and is very resilient in the face of random corruption due to its use of a journal. You can also use XFS which is a very well-written, fast, and mature general-purpose filesystem. If you keep /boot
on the same partition as your main installation, then you will naturally have to use only one filesystem.
If your boot directory is on a separate partition, then you would either want to use ext4 with the journal disabled, or ext2 which lacks a journal in the first place. It may be a good idea to forgo the journal simply because it is unnecessary when there is not going to be a lot of frequent filesystem changes that a journal can protect from corruption, and because it uses up valuable space.
I would recommend ext4 with a disabled journal instead of ext2 simply because the former is faster and is more resistant to corruption, even without the journal, due to the excellent filesystem checker it comes with. You can format a device this way by running mkfs.ext4 -O ^has_journal /dev/sdx1
.
Some of the other general-purpose formats, described very briefly:
ext2 - A simple and fast filesystem with no journal. Good for SD cards.
ext3 - Literally ext2 with a journal duct taped to it. Not a great filesystem.
ext4 - A modern and high-performance filesystem. You should use this.
XFS - Another modern and high-performance filesystem. Good for big partitions.
JFS - The first journaling filesystem. Not the fastest, but it's low on resources.
Btrfs - An "advanced" copy-on-write filesystem that is still pretty buggy.
ReiserFS - Good for many small files, but slow. Its primary developer is still in prison.
There are also a few "specialized" filesystems that are commonly supported:
ZFS - Extremely powerful and amazingly reliable, but requires out-of-tree patches.
FAT - A very simple and widely-supported family of filesystems.
f2fs - Optimized for solid state drives to reduce wear-and-tear.
bcachefs - An upcoming very fast filesystem that makes use of an SSD cache.
For small SD cards or very small partitions, ext2, ext4 without a journal, and FAT are decent choices. For a primary installation, you can't go wrong with the popular ext4 or venerable XFS.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f337196%2fdo-i-use-ext4-for-all-partitions-such-as-and-boot-what-are-the-other-forma%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Swap space doesn't use a filesystem at all. For regular filesystem partitions, my thoughts are:
Ext2fs -- This is the major surviving non-journaled Linux-native filesystem, and as such it has limited utility. I'd only recommend it on a small partition (such as a separate/boot
partition or possibly a small USB flash drive), where the journal will be more of a detriment than an advantage.
Ext3fs -- This is ext2fs plus a journal, which reduces disk-check times after a power failure or system crash. Ext3fs used to be a decent choice, but it's been pretty well eclipsed by ext4fs these days....
Ext4fs -- This is ext3fs plus some new features that improve performance and enable use on larger disks. It's probably the best general-purpose filesystem for Linux these days; certainly it's the one that most distributions favor by default.
ReiserFS -- This filesystem is roughly comparable to ext3fs in features. Its main standout point is that it's especially good at handling small files (as in a few kilobytes, or even under a kilobyte). If you happen to be storing lots of dinky files, it's still worth considering. OTOH, it's not a "hot" filesystem, so development is slow, and ReiserFS lacks the advanced features found in ext4fs and the later filesystems on this list. A variant, Reiser4, promises such features but has been very slow in materializing as an actual in-kernel filesystem. I'm not holding my breath on Reiser4 becoming viable.
XFS -- Favored by system administrators on big disks (over a few terabytes), XFS has some moderately advanced features, and has a good reputation for handling large files. XFS partitions can't be shrunk, though, which can be a problem if you're not sure how big to make your partitions.
JFS -- Similar in many ways to XFS, JFS has never been as popular. A few years ago, it wasn't as reliable, but I'm not sure that's the case any more. I can't think of any good reasons to favor it today on a Linux-only system, although there may be some specialized cases where it would perform better than other filesystems.
Btrfs -- This is the newest Linux-native filesystem, and it includes advanced features like the ability to span a filesystem across multiple disks and to take snapshots. It's still experimental, though, so it's not really recommended for use in production environments.
ph0t0nix mentioned ZFS, but that's not really Linux-native. (It was developed by Sun, and has been ported to some of the BSDs, but licensing issues prevent moving that code into the Linux kernel.) There are two ZFS implementations for Linux, one of which can be built into the kernel and the other of which is a userspace driver accessed via FUSE. The kernel ZFS driver isn't part of the standard Linux kernel, though, which is a big drawback in my view; IMHO, a driver for your main filesystem should be a standard part of the kernel, not an add-on package that might not work if you upgrade your kernel.
Overall, then, and IMHO, the best general-purpose options at the moment are ext4fs and XFS. Of the two, I give the nod to ext4fs because it's more popular and it can be shrunk. Ext2fs is OK on small partitions (say, under 1GB or so), ReiserFS can be good if you store lots of very small files, and Btrfs is good if you need advanced bleeding-edge features and don't mind the risk. I don't happen to have benchmark data handy on these filesystems, and such data can be difficult to interpret because so many factors can influence performance (disk type, file sizes, system load, etc.). You could try looking up such data if speed or system load is particularly important to you.
There are of course non-native filesystems, too -- NTFS, FAT, HFS+, etc. You can't use these as the filesystem for your main Linux installation. (I suppose you might be able to use HFS+ for that purpose, but I've never tried it, and it certainly isn't supported by the Ubuntu installer!) You'd use these for interoperability on dual-boot computers or on removable disks.
While ext3 is indeed ext2 with a journal duct taped to it, I'd say that ext4 isn't really ext3 with extra features. It's a completely rewritten filesystem with totally new features and a journal integrated from the ground up. As for the use-case of JFS, the main reason it might be used is its extremely low resource requirements and its variable-sized filesystem blocks. Other than that, its performance is not ideal (in particular due to the lack of allocate-on-flush/delayed-allocation). Finally, for/boot
, why not just use ext4 with the journal disabled?
– forest
2 days ago
add a comment |
Swap space doesn't use a filesystem at all. For regular filesystem partitions, my thoughts are:
Ext2fs -- This is the major surviving non-journaled Linux-native filesystem, and as such it has limited utility. I'd only recommend it on a small partition (such as a separate/boot
partition or possibly a small USB flash drive), where the journal will be more of a detriment than an advantage.
Ext3fs -- This is ext2fs plus a journal, which reduces disk-check times after a power failure or system crash. Ext3fs used to be a decent choice, but it's been pretty well eclipsed by ext4fs these days....
Ext4fs -- This is ext3fs plus some new features that improve performance and enable use on larger disks. It's probably the best general-purpose filesystem for Linux these days; certainly it's the one that most distributions favor by default.
ReiserFS -- This filesystem is roughly comparable to ext3fs in features. Its main standout point is that it's especially good at handling small files (as in a few kilobytes, or even under a kilobyte). If you happen to be storing lots of dinky files, it's still worth considering. OTOH, it's not a "hot" filesystem, so development is slow, and ReiserFS lacks the advanced features found in ext4fs and the later filesystems on this list. A variant, Reiser4, promises such features but has been very slow in materializing as an actual in-kernel filesystem. I'm not holding my breath on Reiser4 becoming viable.
XFS -- Favored by system administrators on big disks (over a few terabytes), XFS has some moderately advanced features, and has a good reputation for handling large files. XFS partitions can't be shrunk, though, which can be a problem if you're not sure how big to make your partitions.
JFS -- Similar in many ways to XFS, JFS has never been as popular. A few years ago, it wasn't as reliable, but I'm not sure that's the case any more. I can't think of any good reasons to favor it today on a Linux-only system, although there may be some specialized cases where it would perform better than other filesystems.
Btrfs -- This is the newest Linux-native filesystem, and it includes advanced features like the ability to span a filesystem across multiple disks and to take snapshots. It's still experimental, though, so it's not really recommended for use in production environments.
ph0t0nix mentioned ZFS, but that's not really Linux-native. (It was developed by Sun, and has been ported to some of the BSDs, but licensing issues prevent moving that code into the Linux kernel.) There are two ZFS implementations for Linux, one of which can be built into the kernel and the other of which is a userspace driver accessed via FUSE. The kernel ZFS driver isn't part of the standard Linux kernel, though, which is a big drawback in my view; IMHO, a driver for your main filesystem should be a standard part of the kernel, not an add-on package that might not work if you upgrade your kernel.
Overall, then, and IMHO, the best general-purpose options at the moment are ext4fs and XFS. Of the two, I give the nod to ext4fs because it's more popular and it can be shrunk. Ext2fs is OK on small partitions (say, under 1GB or so), ReiserFS can be good if you store lots of very small files, and Btrfs is good if you need advanced bleeding-edge features and don't mind the risk. I don't happen to have benchmark data handy on these filesystems, and such data can be difficult to interpret because so many factors can influence performance (disk type, file sizes, system load, etc.). You could try looking up such data if speed or system load is particularly important to you.
There are of course non-native filesystems, too -- NTFS, FAT, HFS+, etc. You can't use these as the filesystem for your main Linux installation. (I suppose you might be able to use HFS+ for that purpose, but I've never tried it, and it certainly isn't supported by the Ubuntu installer!) You'd use these for interoperability on dual-boot computers or on removable disks.
While ext3 is indeed ext2 with a journal duct taped to it, I'd say that ext4 isn't really ext3 with extra features. It's a completely rewritten filesystem with totally new features and a journal integrated from the ground up. As for the use-case of JFS, the main reason it might be used is its extremely low resource requirements and its variable-sized filesystem blocks. Other than that, its performance is not ideal (in particular due to the lack of allocate-on-flush/delayed-allocation). Finally, for/boot
, why not just use ext4 with the journal disabled?
– forest
2 days ago
add a comment |
Swap space doesn't use a filesystem at all. For regular filesystem partitions, my thoughts are:
Ext2fs -- This is the major surviving non-journaled Linux-native filesystem, and as such it has limited utility. I'd only recommend it on a small partition (such as a separate/boot
partition or possibly a small USB flash drive), where the journal will be more of a detriment than an advantage.
Ext3fs -- This is ext2fs plus a journal, which reduces disk-check times after a power failure or system crash. Ext3fs used to be a decent choice, but it's been pretty well eclipsed by ext4fs these days....
Ext4fs -- This is ext3fs plus some new features that improve performance and enable use on larger disks. It's probably the best general-purpose filesystem for Linux these days; certainly it's the one that most distributions favor by default.
ReiserFS -- This filesystem is roughly comparable to ext3fs in features. Its main standout point is that it's especially good at handling small files (as in a few kilobytes, or even under a kilobyte). If you happen to be storing lots of dinky files, it's still worth considering. OTOH, it's not a "hot" filesystem, so development is slow, and ReiserFS lacks the advanced features found in ext4fs and the later filesystems on this list. A variant, Reiser4, promises such features but has been very slow in materializing as an actual in-kernel filesystem. I'm not holding my breath on Reiser4 becoming viable.
XFS -- Favored by system administrators on big disks (over a few terabytes), XFS has some moderately advanced features, and has a good reputation for handling large files. XFS partitions can't be shrunk, though, which can be a problem if you're not sure how big to make your partitions.
JFS -- Similar in many ways to XFS, JFS has never been as popular. A few years ago, it wasn't as reliable, but I'm not sure that's the case any more. I can't think of any good reasons to favor it today on a Linux-only system, although there may be some specialized cases where it would perform better than other filesystems.
Btrfs -- This is the newest Linux-native filesystem, and it includes advanced features like the ability to span a filesystem across multiple disks and to take snapshots. It's still experimental, though, so it's not really recommended for use in production environments.
ph0t0nix mentioned ZFS, but that's not really Linux-native. (It was developed by Sun, and has been ported to some of the BSDs, but licensing issues prevent moving that code into the Linux kernel.) There are two ZFS implementations for Linux, one of which can be built into the kernel and the other of which is a userspace driver accessed via FUSE. The kernel ZFS driver isn't part of the standard Linux kernel, though, which is a big drawback in my view; IMHO, a driver for your main filesystem should be a standard part of the kernel, not an add-on package that might not work if you upgrade your kernel.
Overall, then, and IMHO, the best general-purpose options at the moment are ext4fs and XFS. Of the two, I give the nod to ext4fs because it's more popular and it can be shrunk. Ext2fs is OK on small partitions (say, under 1GB or so), ReiserFS can be good if you store lots of very small files, and Btrfs is good if you need advanced bleeding-edge features and don't mind the risk. I don't happen to have benchmark data handy on these filesystems, and such data can be difficult to interpret because so many factors can influence performance (disk type, file sizes, system load, etc.). You could try looking up such data if speed or system load is particularly important to you.
There are of course non-native filesystems, too -- NTFS, FAT, HFS+, etc. You can't use these as the filesystem for your main Linux installation. (I suppose you might be able to use HFS+ for that purpose, but I've never tried it, and it certainly isn't supported by the Ubuntu installer!) You'd use these for interoperability on dual-boot computers or on removable disks.
Swap space doesn't use a filesystem at all. For regular filesystem partitions, my thoughts are:
Ext2fs -- This is the major surviving non-journaled Linux-native filesystem, and as such it has limited utility. I'd only recommend it on a small partition (such as a separate/boot
partition or possibly a small USB flash drive), where the journal will be more of a detriment than an advantage.
Ext3fs -- This is ext2fs plus a journal, which reduces disk-check times after a power failure or system crash. Ext3fs used to be a decent choice, but it's been pretty well eclipsed by ext4fs these days....
Ext4fs -- This is ext3fs plus some new features that improve performance and enable use on larger disks. It's probably the best general-purpose filesystem for Linux these days; certainly it's the one that most distributions favor by default.
ReiserFS -- This filesystem is roughly comparable to ext3fs in features. Its main standout point is that it's especially good at handling small files (as in a few kilobytes, or even under a kilobyte). If you happen to be storing lots of dinky files, it's still worth considering. OTOH, it's not a "hot" filesystem, so development is slow, and ReiserFS lacks the advanced features found in ext4fs and the later filesystems on this list. A variant, Reiser4, promises such features but has been very slow in materializing as an actual in-kernel filesystem. I'm not holding my breath on Reiser4 becoming viable.
XFS -- Favored by system administrators on big disks (over a few terabytes), XFS has some moderately advanced features, and has a good reputation for handling large files. XFS partitions can't be shrunk, though, which can be a problem if you're not sure how big to make your partitions.
JFS -- Similar in many ways to XFS, JFS has never been as popular. A few years ago, it wasn't as reliable, but I'm not sure that's the case any more. I can't think of any good reasons to favor it today on a Linux-only system, although there may be some specialized cases where it would perform better than other filesystems.
Btrfs -- This is the newest Linux-native filesystem, and it includes advanced features like the ability to span a filesystem across multiple disks and to take snapshots. It's still experimental, though, so it's not really recommended for use in production environments.
ph0t0nix mentioned ZFS, but that's not really Linux-native. (It was developed by Sun, and has been ported to some of the BSDs, but licensing issues prevent moving that code into the Linux kernel.) There are two ZFS implementations for Linux, one of which can be built into the kernel and the other of which is a userspace driver accessed via FUSE. The kernel ZFS driver isn't part of the standard Linux kernel, though, which is a big drawback in my view; IMHO, a driver for your main filesystem should be a standard part of the kernel, not an add-on package that might not work if you upgrade your kernel.
Overall, then, and IMHO, the best general-purpose options at the moment are ext4fs and XFS. Of the two, I give the nod to ext4fs because it's more popular and it can be shrunk. Ext2fs is OK on small partitions (say, under 1GB or so), ReiserFS can be good if you store lots of very small files, and Btrfs is good if you need advanced bleeding-edge features and don't mind the risk. I don't happen to have benchmark data handy on these filesystems, and such data can be difficult to interpret because so many factors can influence performance (disk type, file sizes, system load, etc.). You could try looking up such data if speed or system load is particularly important to you.
There are of course non-native filesystems, too -- NTFS, FAT, HFS+, etc. You can't use these as the filesystem for your main Linux installation. (I suppose you might be able to use HFS+ for that purpose, but I've never tried it, and it certainly isn't supported by the Ubuntu installer!) You'd use these for interoperability on dual-boot computers or on removable disks.
answered Aug 26 '13 at 3:22
Rod SmithRod Smith
35.3k43870
35.3k43870
While ext3 is indeed ext2 with a journal duct taped to it, I'd say that ext4 isn't really ext3 with extra features. It's a completely rewritten filesystem with totally new features and a journal integrated from the ground up. As for the use-case of JFS, the main reason it might be used is its extremely low resource requirements and its variable-sized filesystem blocks. Other than that, its performance is not ideal (in particular due to the lack of allocate-on-flush/delayed-allocation). Finally, for/boot
, why not just use ext4 with the journal disabled?
– forest
2 days ago
add a comment |
While ext3 is indeed ext2 with a journal duct taped to it, I'd say that ext4 isn't really ext3 with extra features. It's a completely rewritten filesystem with totally new features and a journal integrated from the ground up. As for the use-case of JFS, the main reason it might be used is its extremely low resource requirements and its variable-sized filesystem blocks. Other than that, its performance is not ideal (in particular due to the lack of allocate-on-flush/delayed-allocation). Finally, for/boot
, why not just use ext4 with the journal disabled?
– forest
2 days ago
While ext3 is indeed ext2 with a journal duct taped to it, I'd say that ext4 isn't really ext3 with extra features. It's a completely rewritten filesystem with totally new features and a journal integrated from the ground up. As for the use-case of JFS, the main reason it might be used is its extremely low resource requirements and its variable-sized filesystem blocks. Other than that, its performance is not ideal (in particular due to the lack of allocate-on-flush/delayed-allocation). Finally, for
/boot
, why not just use ext4 with the journal disabled?– forest
2 days ago
While ext3 is indeed ext2 with a journal duct taped to it, I'd say that ext4 isn't really ext3 with extra features. It's a completely rewritten filesystem with totally new features and a journal integrated from the ground up. As for the use-case of JFS, the main reason it might be used is its extremely low resource requirements and its variable-sized filesystem blocks. Other than that, its performance is not ideal (in particular due to the lack of allocate-on-flush/delayed-allocation). Finally, for
/boot
, why not just use ext4 with the journal disabled?– forest
2 days ago
add a comment |
For the setup you propose ext4 is recommended.
If you were to put /boot
as a separate partition, you could use ext2 for that. For large filesystems (e.g. > 16TB I generally use xfs, as it I had some problems with ext4 there (problems when resizing the partition). And btrfs is still not recommended for production. For a server you could consider ZFS, which has been declared stable on Linux a few months ago.
Grub2 don't need to be ext2. Only Grub1 does.
– Braiam
Aug 25 '13 at 22:37
Even GRUB 1 (aka GRUB Legacy) can boot from most Linux filesystems. (I'm not sure about Btrfs, offhand.) The advantage of ext2fs on a small partition is that there's no journal file to consume disk space; on a small partition, the journal file can consume a significant amount of disk space, and the advantages of journaling on a small partition are minimal.
– Rod Smith
Aug 26 '13 at 2:53
@ph0t0nix Large Files System or do you mean large Files? XFS is a good file system when you using as a media center or DVR holding video where files are generally large.
– AngryWombat
Aug 26 '13 at 3:28
1
@AngryWombat: I mean both. At work I manage a couple of filesystems that are large (up to 24TB per filesystem at the moment), some of which contain files of several GB in size (mostly < 10GB, though).
– ph0t0nix
Aug 26 '13 at 7:08
@Ho0t0nix , nice one (have a 1up), I keep that in mind next time... I got do some home work of my own in regards to BtrFS and ZFS working with large file systems. I love the idea behind thesse two FS and what they can do.
– AngryWombat
Sep 1 '13 at 23:53
add a comment |
For the setup you propose ext4 is recommended.
If you were to put /boot
as a separate partition, you could use ext2 for that. For large filesystems (e.g. > 16TB I generally use xfs, as it I had some problems with ext4 there (problems when resizing the partition). And btrfs is still not recommended for production. For a server you could consider ZFS, which has been declared stable on Linux a few months ago.
Grub2 don't need to be ext2. Only Grub1 does.
– Braiam
Aug 25 '13 at 22:37
Even GRUB 1 (aka GRUB Legacy) can boot from most Linux filesystems. (I'm not sure about Btrfs, offhand.) The advantage of ext2fs on a small partition is that there's no journal file to consume disk space; on a small partition, the journal file can consume a significant amount of disk space, and the advantages of journaling on a small partition are minimal.
– Rod Smith
Aug 26 '13 at 2:53
@ph0t0nix Large Files System or do you mean large Files? XFS is a good file system when you using as a media center or DVR holding video where files are generally large.
– AngryWombat
Aug 26 '13 at 3:28
1
@AngryWombat: I mean both. At work I manage a couple of filesystems that are large (up to 24TB per filesystem at the moment), some of which contain files of several GB in size (mostly < 10GB, though).
– ph0t0nix
Aug 26 '13 at 7:08
@Ho0t0nix , nice one (have a 1up), I keep that in mind next time... I got do some home work of my own in regards to BtrFS and ZFS working with large file systems. I love the idea behind thesse two FS and what they can do.
– AngryWombat
Sep 1 '13 at 23:53
add a comment |
For the setup you propose ext4 is recommended.
If you were to put /boot
as a separate partition, you could use ext2 for that. For large filesystems (e.g. > 16TB I generally use xfs, as it I had some problems with ext4 there (problems when resizing the partition). And btrfs is still not recommended for production. For a server you could consider ZFS, which has been declared stable on Linux a few months ago.
For the setup you propose ext4 is recommended.
If you were to put /boot
as a separate partition, you could use ext2 for that. For large filesystems (e.g. > 16TB I generally use xfs, as it I had some problems with ext4 there (problems when resizing the partition). And btrfs is still not recommended for production. For a server you could consider ZFS, which has been declared stable on Linux a few months ago.
answered Aug 25 '13 at 20:17
ph0t0nixph0t0nix
1,0771025
1,0771025
Grub2 don't need to be ext2. Only Grub1 does.
– Braiam
Aug 25 '13 at 22:37
Even GRUB 1 (aka GRUB Legacy) can boot from most Linux filesystems. (I'm not sure about Btrfs, offhand.) The advantage of ext2fs on a small partition is that there's no journal file to consume disk space; on a small partition, the journal file can consume a significant amount of disk space, and the advantages of journaling on a small partition are minimal.
– Rod Smith
Aug 26 '13 at 2:53
@ph0t0nix Large Files System or do you mean large Files? XFS is a good file system when you using as a media center or DVR holding video where files are generally large.
– AngryWombat
Aug 26 '13 at 3:28
1
@AngryWombat: I mean both. At work I manage a couple of filesystems that are large (up to 24TB per filesystem at the moment), some of which contain files of several GB in size (mostly < 10GB, though).
– ph0t0nix
Aug 26 '13 at 7:08
@Ho0t0nix , nice one (have a 1up), I keep that in mind next time... I got do some home work of my own in regards to BtrFS and ZFS working with large file systems. I love the idea behind thesse two FS and what they can do.
– AngryWombat
Sep 1 '13 at 23:53
add a comment |
Grub2 don't need to be ext2. Only Grub1 does.
– Braiam
Aug 25 '13 at 22:37
Even GRUB 1 (aka GRUB Legacy) can boot from most Linux filesystems. (I'm not sure about Btrfs, offhand.) The advantage of ext2fs on a small partition is that there's no journal file to consume disk space; on a small partition, the journal file can consume a significant amount of disk space, and the advantages of journaling on a small partition are minimal.
– Rod Smith
Aug 26 '13 at 2:53
@ph0t0nix Large Files System or do you mean large Files? XFS is a good file system when you using as a media center or DVR holding video where files are generally large.
– AngryWombat
Aug 26 '13 at 3:28
1
@AngryWombat: I mean both. At work I manage a couple of filesystems that are large (up to 24TB per filesystem at the moment), some of which contain files of several GB in size (mostly < 10GB, though).
– ph0t0nix
Aug 26 '13 at 7:08
@Ho0t0nix , nice one (have a 1up), I keep that in mind next time... I got do some home work of my own in regards to BtrFS and ZFS working with large file systems. I love the idea behind thesse two FS and what they can do.
– AngryWombat
Sep 1 '13 at 23:53
Grub2 don't need to be ext2. Only Grub1 does.
– Braiam
Aug 25 '13 at 22:37
Grub2 don't need to be ext2. Only Grub1 does.
– Braiam
Aug 25 '13 at 22:37
Even GRUB 1 (aka GRUB Legacy) can boot from most Linux filesystems. (I'm not sure about Btrfs, offhand.) The advantage of ext2fs on a small partition is that there's no journal file to consume disk space; on a small partition, the journal file can consume a significant amount of disk space, and the advantages of journaling on a small partition are minimal.
– Rod Smith
Aug 26 '13 at 2:53
Even GRUB 1 (aka GRUB Legacy) can boot from most Linux filesystems. (I'm not sure about Btrfs, offhand.) The advantage of ext2fs on a small partition is that there's no journal file to consume disk space; on a small partition, the journal file can consume a significant amount of disk space, and the advantages of journaling on a small partition are minimal.
– Rod Smith
Aug 26 '13 at 2:53
@ph0t0nix Large Files System or do you mean large Files? XFS is a good file system when you using as a media center or DVR holding video where files are generally large.
– AngryWombat
Aug 26 '13 at 3:28
@ph0t0nix Large Files System or do you mean large Files? XFS is a good file system when you using as a media center or DVR holding video where files are generally large.
– AngryWombat
Aug 26 '13 at 3:28
1
1
@AngryWombat: I mean both. At work I manage a couple of filesystems that are large (up to 24TB per filesystem at the moment), some of which contain files of several GB in size (mostly < 10GB, though).
– ph0t0nix
Aug 26 '13 at 7:08
@AngryWombat: I mean both. At work I manage a couple of filesystems that are large (up to 24TB per filesystem at the moment), some of which contain files of several GB in size (mostly < 10GB, though).
– ph0t0nix
Aug 26 '13 at 7:08
@Ho0t0nix , nice one (have a 1up), I keep that in mind next time... I got do some home work of my own in regards to BtrFS and ZFS working with large file systems. I love the idea behind thesse two FS and what they can do.
– AngryWombat
Sep 1 '13 at 23:53
@Ho0t0nix , nice one (have a 1up), I keep that in mind next time... I got do some home work of my own in regards to BtrFS and ZFS working with large file systems. I love the idea behind thesse two FS and what they can do.
– AngryWombat
Sep 1 '13 at 23:53
add a comment |
Use ext4 or XFS for your main partition. Use ext2 or non-journaled ext4 for boot.
You should use ext4 for your main partition. It provides high-performance, is quite stable, and is very resilient in the face of random corruption due to its use of a journal. You can also use XFS which is a very well-written, fast, and mature general-purpose filesystem. If you keep /boot
on the same partition as your main installation, then you will naturally have to use only one filesystem.
If your boot directory is on a separate partition, then you would either want to use ext4 with the journal disabled, or ext2 which lacks a journal in the first place. It may be a good idea to forgo the journal simply because it is unnecessary when there is not going to be a lot of frequent filesystem changes that a journal can protect from corruption, and because it uses up valuable space.
I would recommend ext4 with a disabled journal instead of ext2 simply because the former is faster and is more resistant to corruption, even without the journal, due to the excellent filesystem checker it comes with. You can format a device this way by running mkfs.ext4 -O ^has_journal /dev/sdx1
.
Some of the other general-purpose formats, described very briefly:
ext2 - A simple and fast filesystem with no journal. Good for SD cards.
ext3 - Literally ext2 with a journal duct taped to it. Not a great filesystem.
ext4 - A modern and high-performance filesystem. You should use this.
XFS - Another modern and high-performance filesystem. Good for big partitions.
JFS - The first journaling filesystem. Not the fastest, but it's low on resources.
Btrfs - An "advanced" copy-on-write filesystem that is still pretty buggy.
ReiserFS - Good for many small files, but slow. Its primary developer is still in prison.
There are also a few "specialized" filesystems that are commonly supported:
ZFS - Extremely powerful and amazingly reliable, but requires out-of-tree patches.
FAT - A very simple and widely-supported family of filesystems.
f2fs - Optimized for solid state drives to reduce wear-and-tear.
bcachefs - An upcoming very fast filesystem that makes use of an SSD cache.
For small SD cards or very small partitions, ext2, ext4 without a journal, and FAT are decent choices. For a primary installation, you can't go wrong with the popular ext4 or venerable XFS.
add a comment |
Use ext4 or XFS for your main partition. Use ext2 or non-journaled ext4 for boot.
You should use ext4 for your main partition. It provides high-performance, is quite stable, and is very resilient in the face of random corruption due to its use of a journal. You can also use XFS which is a very well-written, fast, and mature general-purpose filesystem. If you keep /boot
on the same partition as your main installation, then you will naturally have to use only one filesystem.
If your boot directory is on a separate partition, then you would either want to use ext4 with the journal disabled, or ext2 which lacks a journal in the first place. It may be a good idea to forgo the journal simply because it is unnecessary when there is not going to be a lot of frequent filesystem changes that a journal can protect from corruption, and because it uses up valuable space.
I would recommend ext4 with a disabled journal instead of ext2 simply because the former is faster and is more resistant to corruption, even without the journal, due to the excellent filesystem checker it comes with. You can format a device this way by running mkfs.ext4 -O ^has_journal /dev/sdx1
.
Some of the other general-purpose formats, described very briefly:
ext2 - A simple and fast filesystem with no journal. Good for SD cards.
ext3 - Literally ext2 with a journal duct taped to it. Not a great filesystem.
ext4 - A modern and high-performance filesystem. You should use this.
XFS - Another modern and high-performance filesystem. Good for big partitions.
JFS - The first journaling filesystem. Not the fastest, but it's low on resources.
Btrfs - An "advanced" copy-on-write filesystem that is still pretty buggy.
ReiserFS - Good for many small files, but slow. Its primary developer is still in prison.
There are also a few "specialized" filesystems that are commonly supported:
ZFS - Extremely powerful and amazingly reliable, but requires out-of-tree patches.
FAT - A very simple and widely-supported family of filesystems.
f2fs - Optimized for solid state drives to reduce wear-and-tear.
bcachefs - An upcoming very fast filesystem that makes use of an SSD cache.
For small SD cards or very small partitions, ext2, ext4 without a journal, and FAT are decent choices. For a primary installation, you can't go wrong with the popular ext4 or venerable XFS.
add a comment |
Use ext4 or XFS for your main partition. Use ext2 or non-journaled ext4 for boot.
You should use ext4 for your main partition. It provides high-performance, is quite stable, and is very resilient in the face of random corruption due to its use of a journal. You can also use XFS which is a very well-written, fast, and mature general-purpose filesystem. If you keep /boot
on the same partition as your main installation, then you will naturally have to use only one filesystem.
If your boot directory is on a separate partition, then you would either want to use ext4 with the journal disabled, or ext2 which lacks a journal in the first place. It may be a good idea to forgo the journal simply because it is unnecessary when there is not going to be a lot of frequent filesystem changes that a journal can protect from corruption, and because it uses up valuable space.
I would recommend ext4 with a disabled journal instead of ext2 simply because the former is faster and is more resistant to corruption, even without the journal, due to the excellent filesystem checker it comes with. You can format a device this way by running mkfs.ext4 -O ^has_journal /dev/sdx1
.
Some of the other general-purpose formats, described very briefly:
ext2 - A simple and fast filesystem with no journal. Good for SD cards.
ext3 - Literally ext2 with a journal duct taped to it. Not a great filesystem.
ext4 - A modern and high-performance filesystem. You should use this.
XFS - Another modern and high-performance filesystem. Good for big partitions.
JFS - The first journaling filesystem. Not the fastest, but it's low on resources.
Btrfs - An "advanced" copy-on-write filesystem that is still pretty buggy.
ReiserFS - Good for many small files, but slow. Its primary developer is still in prison.
There are also a few "specialized" filesystems that are commonly supported:
ZFS - Extremely powerful and amazingly reliable, but requires out-of-tree patches.
FAT - A very simple and widely-supported family of filesystems.
f2fs - Optimized for solid state drives to reduce wear-and-tear.
bcachefs - An upcoming very fast filesystem that makes use of an SSD cache.
For small SD cards or very small partitions, ext2, ext4 without a journal, and FAT are decent choices. For a primary installation, you can't go wrong with the popular ext4 or venerable XFS.
Use ext4 or XFS for your main partition. Use ext2 or non-journaled ext4 for boot.
You should use ext4 for your main partition. It provides high-performance, is quite stable, and is very resilient in the face of random corruption due to its use of a journal. You can also use XFS which is a very well-written, fast, and mature general-purpose filesystem. If you keep /boot
on the same partition as your main installation, then you will naturally have to use only one filesystem.
If your boot directory is on a separate partition, then you would either want to use ext4 with the journal disabled, or ext2 which lacks a journal in the first place. It may be a good idea to forgo the journal simply because it is unnecessary when there is not going to be a lot of frequent filesystem changes that a journal can protect from corruption, and because it uses up valuable space.
I would recommend ext4 with a disabled journal instead of ext2 simply because the former is faster and is more resistant to corruption, even without the journal, due to the excellent filesystem checker it comes with. You can format a device this way by running mkfs.ext4 -O ^has_journal /dev/sdx1
.
Some of the other general-purpose formats, described very briefly:
ext2 - A simple and fast filesystem with no journal. Good for SD cards.
ext3 - Literally ext2 with a journal duct taped to it. Not a great filesystem.
ext4 - A modern and high-performance filesystem. You should use this.
XFS - Another modern and high-performance filesystem. Good for big partitions.
JFS - The first journaling filesystem. Not the fastest, but it's low on resources.
Btrfs - An "advanced" copy-on-write filesystem that is still pretty buggy.
ReiserFS - Good for many small files, but slow. Its primary developer is still in prison.
There are also a few "specialized" filesystems that are commonly supported:
ZFS - Extremely powerful and amazingly reliable, but requires out-of-tree patches.
FAT - A very simple and widely-supported family of filesystems.
f2fs - Optimized for solid state drives to reduce wear-and-tear.
bcachefs - An upcoming very fast filesystem that makes use of an SSD cache.
For small SD cards or very small partitions, ext2, ext4 without a journal, and FAT are decent choices. For a primary installation, you can't go wrong with the popular ext4 or venerable XFS.
edited yesterday
answered 2 days ago
forestforest
1378
1378
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f337196%2fdo-i-use-ext4-for-all-partitions-such-as-and-boot-what-are-the-other-forma%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown