Re: "Proper" filesystem for Debian installed on a flash drive
On 01.10.21 03:37, Rick Thomas wrote: On Thu, Sep 30, 2021, at 6:02 PM, Nate Bargmann wrote: * On 2021 30 Sep 15:15 -0500, Marco Möller wrote: SUMMARY: I never observed problems with ext4 on my since 4 years heavily used USB pen-drive. Good Luck! Marco Thanks Marco! That is a very useful review of your experience. Your taking the time to write it up is greatly appreciated. - Nate Marco, would you be kind enough to share the manufacturer and other specs of your USB pen drive? Thanks! Rick In detail, I am currently, since 10 month, running as my daily work horse a pen-drive: SAMSUNG Flash Drive Fit, 128 GB, USB 3.1 Vendor ID 0x90c (Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.)) Product ID 0x1000 (Flash Drive) Speed 5.000 Mbit/s, Channels 0, Max. Packet Size 9 This is the one which has only "the small 128 GB" availabe for me. I before for this heavy job used for at least 1.5 years a pen-drive: SanDisk Ultra Fit, 128 GB, USB 2 This is the one which has "the big 128 GB" available for me, and it is still used from time to time, although not heavily anymore since I changed to a meanwhile affordable USB 3 pen-drive last winter (see above). I before for this heavy job used for 2 years a pen-drive: SanDisk Ultra Fit, 64 GB, USB 2. Not so heavily used, mainly for storage with a lot of reading but almost no writing to it I also have in use for many years (5 or 6?) now some pen-drives: SanDisk Ultra Fit, 32 GB, USB 2. SanDisk Ultra Fit, 16 GB, USB 2. All these SanDisk Ultra Fit are this very tiny pen-drives which you hardly see to be inserted to the USB port. Really, I never had a problem with them. Well you noticed that I like this tiny design, it fits nicely into my pocket not letting me carry around any laptop anymore since many years now. I simply take advantage of old hardware (PC or laptops) which others do not want anymore and placed that hardware at my different locations. After the first 16 GB pen-drive of this SanDisk Ultra Flat model worked fine for me I did not change to another model until I couldn't find a USB3 version of them in the local stores (I could get hands on a laptop having a USB 3 port) and therefore then went with the other brand instead of making a big science out of it. I simply trust that my backup plan will please not let me stand in the rain when really in need of it and not only testing that it should work. The only 2 pen-drives which I lost because of hardware failure have been one (long time ago) 4 GB drive from the supermarket (the brand name of this drive I do not remember), and a 32 GB drive of brand "EMS" (also from a supermarket), if I remember the name correctly. The EMS drive was by the way formatted with VFAT. I still have in use, although seldom, some very old 4 GB drives which I use to place some Live Linux Distros or installation medium on it. But these can not be considered to be heavily in use at all. However, at least their shelf live time apparently is quite long, they are all older than 5 to 6 years already and seem to still work fine. Best regards Marco
Re: USB memory stick quality [was: "Proper" filesystem for Debian installed on a flash drive]
On Fri, Oct 01, 2021 at 07:22:22AM -0400, Jude DaShiell wrote: > One more lesson applies to usb memory sticks. All of the guts visit China > before going into the cases with those trademarks on them. Definitely. Tell me where else to find high-skilled cheap labour and good tech infrastructure. Actually I always cringe when I read "China" as a synonym for "cheap, low quality". It's us, expecting a bundle of high tech for $19.95 (and choosing that other for $17.95) who are fueling this sad state of affairs. The folks working at Foxconn would sure take some better labour protection laws had they a choice. Cheers - t signature.asc Description: Digital signature
Re: USB memory stick quality [was: "Proper" filesystem for Debian installed on a flash drive]
One more lesson applies to usb memory sticks. All of the guts visit China before going into the cases with those trademarks on them. On Fri, 1 Oct 2021, Cindy Sue Causey wrote: > On 10/1/21, to...@tuxteam.de wrote: > > > > I take two lessons out of it: > > > > (1) quality of those things scatters widely. Do take Marco's > > advise seriously and have always a Plan B. In my case, it's > > Just A Backup (TM), so I make it so my main disk doesnt > > fail until I find a replacement stick ;-@ > > Left that in because it has applied to all the hardware I've ever > bought. Ages ago, I mused on here that every critical hardware aspect > of computing needs *at least one* backup sitting in a drawer nearby. > At the time, it was probably about something like those ethernet to > USB adapters. It might have been about external dialup modems, too. > > > (2) I have the hunch that the name on the shell bears little > > relation to the guts inside. The latter are whatever the vendor > > putting its name on the outside can scavenge cheaply off the > > market at some point in time. So trading brand names might > > be possibly misleading ;-) > > Am only typing because I just experienced this with keyboards. Six or > eight keyboards were stuffed under my nose in a vendor's email last > night. All looked exactly the same, just had different seller logos on > a nameplate sitting right above the arrow keys. > > Last night the prices were within a couple dollars of each other (plus > the same outrageous shipping). In the past, the prices have sometimes > been $20 apart for what is obviously the exact same item. :) > > Cindy :) >
Re: USB memory stick quality [was: "Proper" filesystem for Debian installed on a flash drive]
On 10/1/21, to...@tuxteam.de wrote: > > I take two lessons out of it: > > (1) quality of those things scatters widely. Do take Marco's > advise seriously and have always a Plan B. In my case, it's > Just A Backup (TM), so I make it so my main disk doesnt > fail until I find a replacement stick ;-@ Left that in because it has applied to all the hardware I've ever bought. Ages ago, I mused on here that every critical hardware aspect of computing needs *at least one* backup sitting in a drawer nearby. At the time, it was probably about something like those ethernet to USB adapters. It might have been about external dialup modems, too. > (2) I have the hunch that the name on the shell bears little > relation to the guts inside. The latter are whatever the vendor > putting its name on the outside can scavenge cheaply off the > market at some point in time. So trading brand names might > be possibly misleading ;-) Am only typing because I just experienced this with keyboards. Six or eight keyboards were stuffed under my nose in a vendor's email last night. All looked exactly the same, just had different seller logos on a nameplate sitting right above the arrow keys. Last night the prices were within a couple dollars of each other (plus the same outrageous shipping). In the past, the prices have sometimes been $20 apart for what is obviously the exact same item. :) Cindy :) -- Cindy-Sue Causey Talking Rock, Pickens County, Georgia, USA * runs with birdseed *
USB memory stick quality [was: "Proper" filesystem for Debian installed on a flash drive]
On Thu, Sep 30, 2021 at 10:13:48PM +0200, Marco Möller wrote: [...] > 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 [...] Not my main file system just the backups, but this is a very important point. I've seen wild variations in quality. The way I do backups is to set up an (LUKS encrypted) ext4 and to rsync the important things (a sprinkling of rsync filters help keeping unnecessary cruft out of the way). That said, I've used one (cute, very small) 64GB stick for years without a problem. Forgot the brand. Once I realised that space was going to be exhausted, I bought a replacement (128GB; lsusb says "ID 13fe:6300 Kingston Technology Company Inc."). It behaved somewhat erratically. I acquired the routine of making an fsck before each backup, and most of the time it would develop file system errors just by sitting on the shelf for some time (days). Next stick. On the shell it says "(Intenso)". Lsusb reports "ID 090c:2000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.)". Its first incarnation started throwing errors two days after buying it (I don't know whether it was "lsusb equivalent" to the current one, mind you). I went to the shop, complained and got a replacement. Since then, an fsck is part of my backup routine (actually two: one before mounting, one after unmounting). After a month, not one failed. Whether it starts some day having more and more failures or it breaks down catastrophically... we'll see. I take two lessons out of it: (1) quality of those things scatters widely. Do take Marco's advise seriously and have always a Plan B. In my case, it's Just A Backup (TM), so I make it so my main disk doesnt fail until I find a replacement stick ;-@ (2) I have the hunch that the name on the shell bears little relation to the guts inside. The latter are whatever the vendor putting its name on the outside can scavenge cheaply off the market at some point in time. So trading brand names might be possibly misleading ;-) Cheers - t signature.asc Description: Digital signature
Re: "Proper" filesystem for Debian installed on a flash drive
Nate Bargmann writes: > That leads me to think that discard could be problematic on some > devices. Does a USB flash drive fall into that category? "USB flash drive" is a little generic. Bottom of the barrel in quality and price are memory sticks like the Sandisk Ultra Fit mentioned and they don't (usually) fall into any category where discard or trim is relevant. A USB SSD, usually yes. Depends on the controller chip though, it needs to be able to pass the trim commands to the drive properly.
Re: "Proper" filesystem for Debian installed on a flash drive
On Thu, Sep 30, 2021, at 6:02 PM, Nate Bargmann wrote: > * On 2021 30 Sep 15:15 -0500, Marco Möller wrote: >> SUMMARY: >> I never observed problems with ext4 on my since 4 years heavily used USB >> pen-drive. >> >> Good Luck! >> Marco > > Thanks Marco! > > That is a very useful review of your experience. Your taking the time > to write it up is greatly appreciated. > > - Nate Marco, would you be kind enough to share the manufacturer and other specs of your USB pen drive? Thanks! Rick
Re: "Proper" filesystem for Debian installed on a flash drive
* On 2021 30 Sep 15:15 -0500, Marco Möller wrote: > SUMMARY: > I never observed problems with ext4 on my since 4 years heavily used USB > pen-drive. > > Good Luck! > Marco Thanks Marco! That is a very useful review of your experience. Your taking the time to write it up is greatly appreciated. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: "Proper" filesystem for Debian installed on a flash drive
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
Re: "Proper" filesystem for Debian installed on a flash drive
Hi. On Wed, Sep 29, 2021 at 08:55:31PM -0500, Nate Bargmann wrote: > * On 2021 29 Sep 09:47 -0500, Reco wrote: > > On Wed, Sep 29, 2021 at 07:59:50AM -0500, Nate Bargmann wrote: > > > 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. > > > > A plain ext4 with the 'discard' mount option will do just fine. > > From the ext4(5) man page: > >discard/nodiscard > Controls whether ext4 should issue discard/TRIM commands to the > underlying block device when blocks are freed. This is useful > for SSD devices and sparse/thinly‐provisioned LUNs, but it is > off by default until sufficient testing has been done. > > LUN? That's new to me. You have to live in a dull enterprise world to use that usually. Take a disk array, partition it one way or another, provide the resulting LUN (i.e. part of the array) to the consumer (server) via FibreChannel. iSCSI has the notion of LUNs too, but to be frank - iSCSI is an overkill for the consumer hardware, and mostly useless if you have FC. And the idea of transferring I/O over TCP is questionable to say the least. > That leads me to think that discard could be problematic on some > devices. It's possible. Luckily, they usually blacklist such problematic SSDs in the kernel itself. I.e. it will function, but TRIM will be ignored. The best way of avoiding such problem is simply not to buy cheap Chinese no-name SSDs. Oh, and ADATA. Never buy *anything* that's produced by them. > Does a USB flash drive fall into that category? Not each USB drive gives you TRIM. Different controller, worse chips, entirely different SCSI commands subset. A typical SD card usually does provide TRIM on the other hand. May depend on a card reader of course. > I've no problem using anacron to run an fstrim(8) job every so often > if discard is thought to be too aggressive. Consider enabling e2scrub if you're running bullseye. Requires LVM, but provides you fsck and fstrim on a mounted filesystem. Disabled by default though. > > > > I understand that the journal can be disabled when using EXT4 to save > > > writes which is probably fine (this system will be non-critical). > > > > It's possible to do, but it is not needed that much. > > If you're trying to conserve drive's resources - just write less on it. > > I.e. redirecting .xsession-errors to /dev/null, removing that annoying > > /var/log/journal directory, adding a good set of filters to rsyslog, > > etc. > > > > For instance, this low-cost SSD that I use in my laptop endured about > > 1.8 Tb writes over 3.5 year usage, and shows no signs of degradation. > > Presumably there is a difference between an SSD which expects a lot of > writes and a USB flash drive that expects relatively few by comparison > used in the role of an SSD/HDD, not? Yup, a crucial one. Modern SSDs, especially good ones (Samsung tend producing those), have impressive durability. You literally need to write tens of terabytes on it to damage it, and the only thing you need to worry about is overheating. USB sticks are just as that - throwaway garbage not guaranteed to survive a single write on it. Form-factor is smaller, and they're detachable, but these are the only redeeming qualities of them. Reco
Re: "Proper" filesystem for Debian installed on a flash drive
* On 2021 29 Sep 09:47 -0500, Reco wrote: > Hi. > > On Wed, Sep 29, 2021 at 07:59:50AM -0500, Nate Bargmann wrote: > > 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. > > A plain ext4 with the 'discard' mount option will do just fine. From the ext4(5) man page: discard/nodiscard Controls whether ext4 should issue discard/TRIM commands to the underlying block device when blocks are freed. This is useful for SSD devices and sparse/thinly‐provisioned LUNs, but it is off by default until sufficient testing has been done. LUN? That's new to me. Let's see[1]: "In computer storage, a logical unit number, or LUN, is a number used to identify a logical unit, which is a device addressed by the SCSI protocol or by Storage Area Network protocols that encapsulate SCSI, such as Fibre Channel or iSCSI." On this desktop I run a cron job twice a month that runs fstrim(8) that its man page states: Running fstrim frequently, or even using mount -o discard, might nega‐ tively affect the lifetime of poor‐quality SSD devices. For most desk‐ top and server systems a sufficient trimming frequency is once a week. Note that not all devices support a queued trim, so each trim command incurs a performance penalty on whatever else might be trying to use the disk at the time. That leads me to think that discard could be problematic on some devices. Does a USB flash drive fall into that category? I've no problem using anacron to run an fstrim(8) job every so often if discard is thought to be too aggressive. > > I understand that the journal can be disabled when using EXT4 to save > > writes which is probably fine (this system will be non-critical). > > It's possible to do, but it is not needed that much. > If you're trying to conserve drive's resources - just write less on it. > I.e. redirecting .xsession-errors to /dev/null, removing that annoying > /var/log/journal directory, adding a good set of filters to rsyslog, > etc. > > For instance, this low-cost SSD that I use in my laptop endured about > 1.8 Tb writes over 3.5 year usage, and shows no signs of degradation. Presumably there is a difference between an SSD which expects a lot of writes and a USB flash drive that expects relatively few by comparison used in the role of an SSD/HDD, not? - Nate [1] https://en.wikipedia.org/wiki/Logical_unit_number -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: "Proper" filesystem for Debian installed on a flash drive
* On 2021 29 Sep 16:40 -0500, David Christensen wrote: > I have several SanDisk UltraFit USB 3.0 Flash Drive 16 GB, and have > installed Debian onto them using btrfs and ext4. Both filesystems work. > btrfs requires periodic re-balancing, which is time consuming. A few years back I built up a server of sorts using BTRFS on a pair of 1 TB 2.5" spinning drives as a software RAID. I think it worked okay but I never got around to really using it as originally conceived. Some time down the road one of the drives started a clicking noise and that was the end of the RAID as I dismantled it. I have a Freedom Box Pioneer that uses BTRFS on its microSD. It seems to be fine. One of BTRFS' features I really like are subvolumes (IIRC) where each subvolume can be be treated as a partition but the FS treats them somewhat like directories and the entire disk is shared between them. Unfortunately, there are still alleged bugs in BTRFS that give me pause. For my usage they would likely be inconsequential. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: "Proper" filesystem for Debian installed on a flash drive
* On 2021 29 Sep 12:50 -0500, Brian wrote: > On Wed 29 Sep 2021 at 11:34:22 -0500, Nate Bargmann wrote: > > > Thanks, Reco. That is useful to me. > > Your question and Reco's response were also useful to me, if only > because I had not come across F2FS previously. On a USB device I > use ext44 without any noticable problems. I have as well, Brian. Even so, I'm always looking for "better" as tech progresses. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: "Proper" filesystem for Debian installed on a flash drive
On 9/29/21 05: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 have several SanDisk UltraFit USB 3.0 Flash Drive 16 GB, and have installed Debian onto them using btrfs and ext4. Both filesystems work. btrfs requires periodic re-balancing, which is time consuming. David
Re: "Proper" filesystem for Debian installed on a flash drive
On Wed 29 Sep 2021 at 11:34:22 -0500, Nate Bargmann wrote: > Thanks, Reco. That is useful to me. Your question and Reco's response were also useful to me, if only because I had not come across F2FS previously. On a USB device I use ext44 without any noticable problems. -- Brian.
Re: "Proper" filesystem for Debian installed on a flash drive
Thanks, Reco. That is useful to me. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: "Proper" filesystem for Debian installed on a flash drive
Hi. On Wed, Sep 29, 2021 at 07:59:50AM -0500, Nate Bargmann wrote: > 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. A plain ext4 with the 'discard' mount option will do just fine. > I understand that the journal can be disabled when using EXT4 to save > writes which is probably fine (this system will be non-critical). It's possible to do, but it is not needed that much. If you're trying to conserve drive's resources - just write less on it. I.e. redirecting .xsession-errors to /dev/null, removing that annoying /var/log/journal directory, adding a good set of filters to rsyslog, etc. For instance, this low-cost SSD that I use in my laptop endured about 1.8 Tb writes over 3.5 year usage, and shows no signs of degradation. >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. They do not do it, because to F2FS is designed to operate over raw NAND chips, not typical SATA/NVMe controller. In layman terms, F2FS is something that's suitable for your phone, or your router, but not your PC. So again, it's possible to do, but again, it's not really needed. Reco
"Proper" filesystem for Debian installed on a flash drive
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 -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
