Which filesystem should I use in an SD card on a NAS?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
My NAS can hold several 3.5" hard drives and an SD card. I'm planning to boot and run a custom Linux system (based on Debian, built by me) from an SD card, and the 3.5" hard drives will be used for data storage (and possibly log files). The SD card has a sequential read and write speed of 90 MB/s.
Which Linux filesystem should I use? Is there a filesystem which provides better speed and longer hardware lifetime (if there are many log file writes) than ext4?
What are the recommended ext4 creation and mount flags for SD cards?
linux filesystems sd-card root-filesystem nas
asked Nov 29 '17 at 0:48
pts
345312
add a comment |Â
up vote
1
down vote
favorite
My NAS can hold several 3.5" hard drives and an SD card. I'm planning to boot and run a custom Linux system (based on Debian, built by me) from an SD card, and the 3.5" hard drives will be used for data storage (and possibly log files). The SD card has a sequential read and write speed of 90 MB/s.
Which Linux filesystem should I use? Is there a filesystem which provides better speed and longer hardware lifetime (if there are many log file writes) than ext4?
What are the recommended ext4 creation and mount flags for SD cards?
linux filesystems sd-card root-filesystem nas
asked Nov 29 '17 at 0:48
pts
345312
1
Don't overcomplicate, ext4. But it is only my opinion. Helló pts :-)
– peterh
Nov 29 '17 at 1:56
@peterh I agree. SD prices are cheap as chips. Journalling r/w can be controlled through the mount options and the SD wear can be monitored for clone/swap out before any real issues arise. My main concern would be the I/O speed on the SD. I ran my lappie from an OS on SD for a while when my I had motherboard issues with my SSD socket. Sloooow to boot, although with enough ram performance was acceptable.
– bu5hman
Nov 29 '17 at 3:58
how about none? boot from it and transfer control as possible to a hard disk.
– Rui F Ribeiro
Nov 29 '17 at 4:40
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
My NAS can hold several 3.5" hard drives and an SD card. I'm planning to boot and run a custom Linux system (based on Debian, built by me) from an SD card, and the 3.5" hard drives will be used for data storage (and possibly log files). The SD card has a sequential read and write speed of 90 MB/s.
Which Linux filesystem should I use? Is there a filesystem which provides better speed and longer hardware lifetime (if there are many log file writes) than ext4?
What are the recommended ext4 creation and mount flags for SD cards?
linux filesystems sd-card root-filesystem nas
asked Nov 29 '17 at 0:48
pts
345312
My NAS can hold several 3.5" hard drives and an SD card. I'm planning to boot and run a custom Linux system (based on Debian, built by me) from an SD card, and the 3.5" hard drives will be used for data storage (and possibly log files). The SD card has a sequential read and write speed of 90 MB/s.
Which Linux filesystem should I use? Is there a filesystem which provides better speed and longer hardware lifetime (if there are many log file writes) than ext4?
What are the recommended ext4 creation and mount flags for SD cards?
linux filesystems sd-card root-filesystem nas
asked Nov 29 '17 at 0:48
pts
345312
asked Nov 29 '17 at 0:48
pts
345312
asked Nov 29 '17 at 0:48
pts
345312
asked Nov 29 '17 at 0:48
pts
345312
345312
1
Don't overcomplicate, ext4. But it is only my opinion. Helló pts :-)
– peterh
Nov 29 '17 at 1:56
@peterh I agree. SD prices are cheap as chips. Journalling r/w can be controlled through the mount options and the SD wear can be monitored for clone/swap out before any real issues arise. My main concern would be the I/O speed on the SD. I ran my lappie from an OS on SD for a while when my I had motherboard issues with my SSD socket. Sloooow to boot, although with enough ram performance was acceptable.
– bu5hman
Nov 29 '17 at 3:58
how about none? boot from it and transfer control as possible to a hard disk.
– Rui F Ribeiro
Nov 29 '17 at 4:40
add a comment |Â
1
Don't overcomplicate, ext4. But it is only my opinion. Helló pts :-)
– peterh
Nov 29 '17 at 1:56
@peterh I agree. SD prices are cheap as chips. Journalling r/w can be controlled through the mount options and the SD wear can be monitored for clone/swap out before any real issues arise. My main concern would be the I/O speed on the SD. I ran my lappie from an OS on SD for a while when my I had motherboard issues with my SSD socket. Sloooow to boot, although with enough ram performance was acceptable.
– bu5hman
Nov 29 '17 at 3:58
how about none? boot from it and transfer control as possible to a hard disk.
– Rui F Ribeiro
Nov 29 '17 at 4:40
1
1
Don't overcomplicate, ext4. But it is only my opinion. Helló pts :-)
– peterh
Nov 29 '17 at 1:56
Don't overcomplicate, ext4. But it is only my opinion. Helló pts :-)
– peterh
Nov 29 '17 at 1:56
@peterh I agree. SD prices are cheap as chips. Journalling r/w can be controlled through the mount options and the SD wear can be monitored for clone/swap out before any real issues arise. My main concern would be the I/O speed on the SD. I ran my lappie from an OS on SD for a while when my I had motherboard issues with my SSD socket. Sloooow to boot, although with enough ram performance was acceptable.
– bu5hman
Nov 29 '17 at 3:58
@peterh I agree. SD prices are cheap as chips. Journalling r/w can be controlled through the mount options and the SD wear can be monitored for clone/swap out before any real issues arise. My main concern would be the I/O speed on the SD. I ran my lappie from an OS on SD for a while when my I had motherboard issues with my SSD socket. Sloooow to boot, although with enough ram performance was acceptable.
– bu5hman
Nov 29 '17 at 3:58
how about none? boot from it and transfer control as possible to a hard disk.
– Rui F Ribeiro
Nov 29 '17 at 4:40
how about none? boot from it and transfer control as possible to a hard disk.
– Rui F Ribeiro
Nov 29 '17 at 4:40
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
1
down vote
The filesystem is largely a matter of personal preference. Ext4 is tried and tested and resilient.
Your filesystem r/w speed will be governed by the SD card so going for a higher performance filesystem will give you no advantage or improvement. You may be able to increase the 'apparent' speed of i/o by increasing the buffer size (ram).
The debate on SD / SSD damage with i/o will not be resolved on this forum, but whichever filesystem you use, if you want to reduce SD i/o then the
noatime
option for ext4 mounts tells the system not to update each file/directory inode at each access.
answered Nov 29 '17 at 4:17
bu5hman
1,164214
add a comment |Â
up vote
0
down vote
Here is the info I was able to find online.
https://en.wikipedia.org/wiki/Flash_file_system#Linux_flash_filesystems mentions JFFS, JFFS2, YAFFS, UBIFS, LogFS, F2FS. Some of these (but not F2FS) are targeted for raw flash devices, F2FS is targeted for flash-based storage devices which already have a translation layer, such as SD cards.
I've found this 2011 question useful about the filesystems available back the: https://superuser.com/questions/248078/choice-of-filesystem-for-gnu-linux-on-an-sd-card
https://developer.ridgerun.com/wiki/index.php/High_performance_SD_card_tuning_using_the_EXT4_file_system mentions ext4 mount flags -o noatime,data=writeback and explains how to create such an ext4 filesystem. It also recommends some cache settings in /proc/sys/vm for increased performance.
https://wiki.gentoo.org/wiki/SDCard#Filesystem mentions some ext4 performance tuning settings which specify block sizes.
answered Nov 29 '17 at 13:54
pts
345312
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
The filesystem is largely a matter of personal preference. Ext4 is tried and tested and resilient.
Your filesystem r/w speed will be governed by the SD card so going for a higher performance filesystem will give you no advantage or improvement. You may be able to increase the 'apparent' speed of i/o by increasing the buffer size (ram).
The debate on SD / SSD damage with i/o will not be resolved on this forum, but whichever filesystem you use, if you want to reduce SD i/o then the
noatime
option for ext4 mounts tells the system not to update each file/directory inode at each access.
answered Nov 29 '17 at 4:17
bu5hman
1,164214
add a comment |Â
up vote
1
down vote
The filesystem is largely a matter of personal preference. Ext4 is tried and tested and resilient.
Your filesystem r/w speed will be governed by the SD card so going for a higher performance filesystem will give you no advantage or improvement. You may be able to increase the 'apparent' speed of i/o by increasing the buffer size (ram).
The debate on SD / SSD damage with i/o will not be resolved on this forum, but whichever filesystem you use, if you want to reduce SD i/o then the
noatime
option for ext4 mounts tells the system not to update each file/directory inode at each access.
answered Nov 29 '17 at 4:17
bu5hman
1,164214
add a comment |Â
up vote
1
down vote
up vote
1
down vote
The filesystem is largely a matter of personal preference. Ext4 is tried and tested and resilient.
Your filesystem r/w speed will be governed by the SD card so going for a higher performance filesystem will give you no advantage or improvement. You may be able to increase the 'apparent' speed of i/o by increasing the buffer size (ram).
The debate on SD / SSD damage with i/o will not be resolved on this forum, but whichever filesystem you use, if you want to reduce SD i/o then the
noatime
option for ext4 mounts tells the system not to update each file/directory inode at each access.
answered Nov 29 '17 at 4:17
bu5hman
1,164214
The filesystem is largely a matter of personal preference. Ext4 is tried and tested and resilient.
Your filesystem r/w speed will be governed by the SD card so going for a higher performance filesystem will give you no advantage or improvement. You may be able to increase the 'apparent' speed of i/o by increasing the buffer size (ram).
The debate on SD / SSD damage with i/o will not be resolved on this forum, but whichever filesystem you use, if you want to reduce SD i/o then the
noatime
option for ext4 mounts tells the system not to update each file/directory inode at each access.
answered Nov 29 '17 at 4:17
bu5hman
1,164214
answered Nov 29 '17 at 4:17
bu5hman
1,164214
answered Nov 29 '17 at 4:17
bu5hman
1,164214
answered Nov 29 '17 at 4:17
bu5hman
1,164214
1,164214
add a comment |Â
add a comment |Â
up vote
0
down vote
Here is the info I was able to find online.
https://en.wikipedia.org/wiki/Flash_file_system#Linux_flash_filesystems mentions JFFS, JFFS2, YAFFS, UBIFS, LogFS, F2FS. Some of these (but not F2FS) are targeted for raw flash devices, F2FS is targeted for flash-based storage devices which already have a translation layer, such as SD cards.
I've found this 2011 question useful about the filesystems available back the: https://superuser.com/questions/248078/choice-of-filesystem-for-gnu-linux-on-an-sd-card
https://developer.ridgerun.com/wiki/index.php/High_performance_SD_card_tuning_using_the_EXT4_file_system mentions ext4 mount flags -o noatime,data=writeback and explains how to create such an ext4 filesystem. It also recommends some cache settings in /proc/sys/vm for increased performance.
https://wiki.gentoo.org/wiki/SDCard#Filesystem mentions some ext4 performance tuning settings which specify block sizes.
answered Nov 29 '17 at 13:54
pts
345312
add a comment |Â
up vote
0
down vote
Here is the info I was able to find online.
https://en.wikipedia.org/wiki/Flash_file_system#Linux_flash_filesystems mentions JFFS, JFFS2, YAFFS, UBIFS, LogFS, F2FS. Some of these (but not F2FS) are targeted for raw flash devices, F2FS is targeted for flash-based storage devices which already have a translation layer, such as SD cards.
I've found this 2011 question useful about the filesystems available back the: https://superuser.com/questions/248078/choice-of-filesystem-for-gnu-linux-on-an-sd-card
https://developer.ridgerun.com/wiki/index.php/High_performance_SD_card_tuning_using_the_EXT4_file_system mentions ext4 mount flags -o noatime,data=writeback and explains how to create such an ext4 filesystem. It also recommends some cache settings in /proc/sys/vm for increased performance.
https://wiki.gentoo.org/wiki/SDCard#Filesystem mentions some ext4 performance tuning settings which specify block sizes.
answered Nov 29 '17 at 13:54
pts
345312
add a comment |Â
up vote
0
down vote
up vote
0
down vote
Here is the info I was able to find online.
https://en.wikipedia.org/wiki/Flash_file_system#Linux_flash_filesystems mentions JFFS, JFFS2, YAFFS, UBIFS, LogFS, F2FS. Some of these (but not F2FS) are targeted for raw flash devices, F2FS is targeted for flash-based storage devices which already have a translation layer, such as SD cards.
I've found this 2011 question useful about the filesystems available back the: https://superuser.com/questions/248078/choice-of-filesystem-for-gnu-linux-on-an-sd-card
https://developer.ridgerun.com/wiki/index.php/High_performance_SD_card_tuning_using_the_EXT4_file_system mentions ext4 mount flags -o noatime,data=writeback and explains how to create such an ext4 filesystem. It also recommends some cache settings in /proc/sys/vm for increased performance.
https://wiki.gentoo.org/wiki/SDCard#Filesystem mentions some ext4 performance tuning settings which specify block sizes.
answered Nov 29 '17 at 13:54
pts
345312
Here is the info I was able to find online.
https://en.wikipedia.org/wiki/Flash_file_system#Linux_flash_filesystems mentions JFFS, JFFS2, YAFFS, UBIFS, LogFS, F2FS. Some of these (but not F2FS) are targeted for raw flash devices, F2FS is targeted for flash-based storage devices which already have a translation layer, such as SD cards.
I've found this 2011 question useful about the filesystems available back the: https://superuser.com/questions/248078/choice-of-filesystem-for-gnu-linux-on-an-sd-card
https://developer.ridgerun.com/wiki/index.php/High_performance_SD_card_tuning_using_the_EXT4_file_system mentions ext4 mount flags -o noatime,data=writeback and explains how to create such an ext4 filesystem. It also recommends some cache settings in /proc/sys/vm for increased performance.
https://wiki.gentoo.org/wiki/SDCard#Filesystem mentions some ext4 performance tuning settings which specify block sizes.
answered Nov 29 '17 at 13:54
pts
345312
answered Nov 29 '17 at 13:54
pts
345312
answered Nov 29 '17 at 13:54
pts
345312
answered Nov 29 '17 at 13:54
pts
345312
345312
add a comment |Â
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f407623%2fwhich-filesystem-should-i-use-in-an-sd-card-on-a-nas%23new-answer', 'question_page');
);
Post as a guest
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
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
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
1
Don't overcomplicate, ext4. But it is only my opinion. Helló pts :-)
– peterh
Nov 29 '17 at 1:56
@peterh I agree. SD prices are cheap as chips. Journalling r/w can be controlled through the mount options and the SD wear can be monitored for clone/swap out before any real issues arise. My main concern would be the I/O speed on the SD. I ran my lappie from an OS on SD for a while when my I had motherboard issues with my SSD socket. Sloooow to boot, although with enough ram performance was acceptable.
– bu5hman
Nov 29 '17 at 3:58
how about none? boot from it and transfer control as possible to a hard disk.
– Rui F Ribeiro
Nov 29 '17 at 4:40