On 29.09.21 14:59, Nate Bargmann wrote:
Earlier this year I purchased a nice Lenovo Carbon X1 with an NVME SSD
with Win 10 Pro installed. Ordinarily I would reformat the drive
without a second thought but in this case I really do have occasional
need to use Win 10 (Kenwood radio programming mostly) and since swapping
the NVME is not trivial, I've opted to install Bullseye to a USB flash
drive.
A test run with KDE Plasma shows that performance is acceptable even
with EXT4 as the file system. I now have some SanDisk Ultra Fit flash
drives arriving in 128GB capacity (overkill, oh well). I am now
considering what file system would be proper to use in this case. I
understand that the journal can be disabled when using EXT4 to save
writes which is probably fine (this system will be non-critical). I've
also seen that F2FS has been available in the kernel since 3.8, but I'm
unsure whether the installer from a Debian live CD will offer it as a
choice.
The Arch Wiki notes some issues with its fsck and the Debian Wiki is
rather short on details. I found this page[1] that was from 2013 and
updated early last year. The process is not trivial which hints that
F2FS is not included in the Buster installer, at least.
As this is a non-typical installation for a dual-boot configuration that
intends to use UEFI to choose the OS to run, are there tips and
suggestions for this? I have already solved the bug where MS places its
boot image in a directory in the ESP that prevents an EFI enabled
removable media from booting[2] (second paragraph).
TIA
- Nate
[1] https://howtos.davidsebek.com/debian-f2fs.html
[2]
https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path
I am running a (LVM LUKS encrypted) Debian on ext4 file system since 4
years from an USB pen-drive and carry it around between various
PCs/Laptops without problems concerning the USB hardware or file system
or alike. The only problems have been the ones which you would the same
also have had by using a not portable installation environment, the
usual problems any Linux user might face from time to time, usually
concerning configuration issues after having upgraded software. Local
hard disk drivers are used by me only for storage of my MP3s at home,
some other big software packages which I downloaded for installing them
to the USB drive, huge amount of image data collected with my
microscopes, and alike, but I do not use my HDDs anymore for the OS or
usual home directory. My portable Debian USB pen-drive system up to now
worked flawlessly.
What I suggest you to consider:
(1) Although never having had trouble myself, for being prepared for a
USB hardware failure, which others are warning of, I "dd" the full
USB-Stick every couple of weeks to some of the HDDs, and of course make
(incremental, deduplicated) backups of the home directory at each
shutdown, thus daily 1 to about 3 times. In the case of a USB pen-drive
crash I could simply purchase a next device, move by "dd" the latest
image to it, run "apt update && apt upgrade", and recover from the home
directory backup all user data up to the latest state.
(2) Use only less than 95% of the volume of your USB storage hardware
for the full system installation (all LVM / partitions / filesystems):
128 GB from the one manufacturer do not equal 128 GB from the other
manufacturer and if having to recover from the "dd" image, then you want
to avoid that the new (still empty) 128 GB is too small for the old 128
GB from the backup! The manufacturers claim there devices to provide 128
GB, but it appears that these 128 GB are not equally available for you
but kept by the device as maybe cache or maybe fall back memory for the
case some memory position would start to fail. Actually I do not really
know where the missing Gigs are, but I have had exactly this case when I
thought to "dd" directly to a next stick, to clone my system as a backup
instead of storing a "dd" image of it on a HDD. I to my surprise found
that the newer, faster, even more expensive 128 GB hardware offered only
124(?) GB. Therefor I reinstalled a volume reduced system or would have
had to purchase 128 GB sticks until I would have found one big enough to
again provide as much 128 GB storage as my original hardware has, in
order to be able to rely on my backup strategy.
(3) In order to in general reduce unnecessary writes to the ext4 file
system I for my usage scenario configured in /etc/mtab
/dev/mapper/lv_root / ext4 rw,noatime,errors=remount-ro,commit=600 0 0
/dev/mapper/lv_home /home ext4
rw,noatime,errors=remount-ro,commit=600 0 0
Note that it is configured noatime and commit.
(4) In the past I found extreme(!) I/O to be produced by Firefox, when
it is writing its cache, and when it is writing its session restore
information. These writes to my observation occur all the time, kind of
nonstop! I could get it very satisfactorily reduced by applying a tool
called "Profile Sync Daemon" (psd) from package "profile-sync-daemon".
While it is packaged for Debian, as a starting point to study its
documentation I suggest to better look it up in the Arch Linux Wiki.
Concerning (3) and (4), I call after saving very important data changes
in a terminal window "sudo sync", hoping that this indeed writes
everything immediately from caches to the disk although "commit" is
specified in my mtab. (If someone would teach me if "sync" is indeed
bypassing the "commit" configuration in /etc/mtab, then I would
appreciate it!)
SUMMARY:
I never observed problems with ext4 on my since 4 years heavily used USB
pen-drive.
Good Luck!
Marco
