Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.os.linux > #81092 > unrolled thread
| Started by | Daniel70 <daniel47@eternal-september.org> |
|---|---|
| First post | 2025-03-11 21:52 +1100 |
| Last post | 2025-03-17 11:54 -0400 |
| Articles | 20 on this page of 83 — 15 participants |
Back to article view | Back to alt.os.linux
When I back-up .... Coping my Entire Internal HD to an external HD Daniel70 <daniel47@eternal-september.org> - 2025-03-11 21:52 +1100
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-11 13:16 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Daniel70 <daniel47@eternal-september.org> - 2025-03-11 23:34 +1100
Re: When I back-up .... Coping my Entire Internal HD to an external HD "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2025-03-11 08:21 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-11 15:57 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD "David W. Hodgins" <dwhodgins@nomail.afraid.org> - 2025-03-11 11:23 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-12 00:31 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Java Jive <java@evij.com.invalid> - 2025-03-12 13:15 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD TJ <TJ@noneofyour.business> - 2025-03-14 11:19 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD "R.Wieser" <address@is.invalid> - 2025-03-14 16:47 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD TJ <TJ@noneofyour.business> - 2025-03-14 14:47 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-14 23:39 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD "R.Wieser" <address@is.invalid> - 2025-03-15 07:50 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-15 06:58 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-15 04:02 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-15 22:20 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-15 20:29 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-16 01:18 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-15 22:44 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-16 06:33 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Dan Purgert <dan@djph.net> - 2025-03-17 08:57 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2025-03-17 16:05 +0200
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-17 19:23 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-17 15:21 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E. R." <robin_listas@es.invalid> - 2025-03-17 22:04 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-17 23:19 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2025-03-19 16:45 +0200
Re: When I back-up .... Coping my Entire Internal HD to an external HD ant@zimage.comANT (Ant) - 2025-03-19 16:05 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-19 21:00 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-20 03:04 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-20 22:02 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-21 11:50 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-21 12:21 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-24 00:50 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-24 14:23 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-20 12:24 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-20 22:01 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-21 11:51 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-21 10:16 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-22 13:52 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-22 14:18 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-22 23:20 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-24 23:20 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-25 12:55 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-26 00:27 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2025-03-20 11:07 +0200
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-20 12:29 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-19 14:14 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-19 21:18 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> - 2025-03-20 10:51 +0200
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-20 12:22 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD TJ <TJ@noneofyour.business> - 2025-03-20 20:35 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-21 11:55 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Joerg Walther <joerg.walther@magenta.de> - 2025-03-21 16:24 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-22 06:58 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-22 04:29 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-22 22:00 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-23 02:01 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-24 00:43 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD TJ <TJ@noneofyour.business> - 2025-03-21 16:37 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-22 06:57 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-22 14:00 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD TJ <TJ@noneofyour.business> - 2025-03-22 09:42 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-22 15:20 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-22 14:00 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-22 20:34 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-22 22:02 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-22 23:22 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-24 00:42 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-17 23:18 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD "R.Wieser" <address@is.invalid> - 2025-03-15 09:08 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-15 13:37 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD "R.Wieser" <address@is.invalid> - 2025-03-15 19:22 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-15 14:57 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD "R.Wieser" <address@is.invalid> - 2025-03-15 21:06 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-11 19:56 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD Richard Kettlewell <invalid@invalid.invalid> - 2025-03-11 18:16 +0000
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-11 20:03 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD "Carlos E.R." <robin_listas@es.invalid> - 2025-03-12 15:12 +0100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-12 14:56 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD bad sector <forgetski@_INVALID.net> - 2025-03-17 07:49 -0400
Re: When I back-up .... Coping my Entire Internal HD to an external HD Daniel70 <daniel47@eternal-september.org> - 2025-03-18 00:21 +1100
Re: When I back-up .... Coping my Entire Internal HD to an external HD Paul <nospam@needed.invalid> - 2025-03-17 11:54 -0400
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2025-03-17 08:57 +0000 |
| Message-ID | <slrnvtfov7.2ff.dan@djph.net> |
| In reply to | #81117 |
On 2025-03-15, Lawrence D'Oliveiro wrote: > On Sat, 15 Mar 2025 04:02:15 -0400, Paul wrote: > >> For a period of time, one of the Windows OSes decided to stop >> listing filesystems that did not need "Safely Remove" behavior, but >> the changes to that OS may have been reversed. > > That’s the thing. Windows is full of assumptions as to which kinds of > devices are allowed to have which kinds of filesystems installed on them, > which kinds are to be hot-pluggable and which are not. > > For example, are you allowed to put NTFS on a hot-pluggable volume? > Somehow, I don’t think so. Practically every USB stick in existence would like to disagree. -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> |
|---|---|
| Date | 2025-03-17 16:05 +0200 |
| Message-ID | <sm0senbu50k.fsf@lakka.kapsi.fi> |
| In reply to | #81123 |
Dan Purgert <dan@djph.net> writes: > On 2025-03-15, Lawrence D'Oliveiro wrote: >> For example, are you allowed to put NTFS on a hot-pluggable volume? >> Somehow, I don’t think so. > > Practically every USB stick in existence would like to disagree. Those are usually FAT formatted. FAT32 or the newer exFAT. No issue reformatting to NTFS though. I've actually found NTFS on a USB SSD to be surprisingly widely supported on media players and TVs and such. I've used it on Android too. So NTFS has become my go-to portable FS.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-17 19:23 +0100 |
| Message-ID | <7t5malx9rp.ln2@Telcontar.valinor> |
| In reply to | #81127 |
On 2025-03-17 15:05, Anssi Saari wrote: > Dan Purgert <dan@djph.net> writes: > >> On 2025-03-15, Lawrence D'Oliveiro wrote: > >>> For example, are you allowed to put NTFS on a hot-pluggable volume? >>> Somehow, I don’t think so. >> >> Practically every USB stick in existence would like to disagree. > > Those are usually FAT formatted. FAT32 or the newer exFAT. No issue > reformatting to NTFS though. > > I've actually found NTFS on a USB SSD to be surprisingly widely > supported on media players and TVs and such. I've used it on Android > too. So NTFS has become my go-to portable FS. exFAT is better, but few TV sets support it, while many support NTFS. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-03-17 15:21 -0400 |
| Message-ID | <vr9sno$p83v$1@dont-email.me> |
| In reply to | #81129 |
On Mon, 3/17/2025 2:23 PM, Carlos E.R. wrote: > On 2025-03-17 15:05, Anssi Saari wrote: >> Dan Purgert <dan@djph.net> writes: >> >>> On 2025-03-15, Lawrence D'Oliveiro wrote: >> >>>> For example, are you allowed to put NTFS on a hot-pluggable volume? >>>> Somehow, I don’t think so. >>> >>> Practically every USB stick in existence would like to disagree. >> >> Those are usually FAT formatted. FAT32 or the newer exFAT. No issue >> reformatting to NTFS though. >> >> I've actually found NTFS on a USB SSD to be surprisingly widely >> supported on media players and TVs and such. I've used it on Android >> too. So NTFS has become my go-to portable FS. > > exFAT is better, but few TV sets support it, while many support NTFS. > EXFAT requires a license. NTFS requires a license. FAT32 requires a license (or at least TomTom may have discovered it did :-) ) One difference is, some applications of EXFAT are covered by FRAND (where EXFAT is defined in a standards doc, as the default filesystem for a certain piece of hardware). In any case, whether license terms are fair and reasonable, or are the normal kind of license terms, equipment makers will not pay a penny more for licensing. It does not latter what the license fee is, they don't want to pay it, whatever it is. NTFS is journaled. NTFS is slightly harder on a USB stick, from a wear perspective. You can improve the characteristics a tiny bit, by disabling "LastAccessed". FAT32 and EXFAT are not journaled. You can set the cluster size on FAT32 and EXFAT (make it greater than or equal to the flash page size). BTFS supports extra large clusters, but the option is not backward compatible (a Win11 NTFS partition with one megabyte clusters, cannot be mounted by Windows XP, or by Windows 7). And that doesn't include testing the Linux response, as if an option isn't intended to be compatible, nobody is going to use it. Paul
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E. R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-17 22:04 +0100 |
| Message-ID | <m3rh2cFna8uU1@mid.individual.net> |
| In reply to | #81130 |
On 2025-03-17 20:21, Paul wrote:
> On Mon, 3/17/2025 2:23 PM, Carlos E.R. wrote:
>> On 2025-03-17 15:05, Anssi Saari wrote:
>>> Dan Purgert <dan@djph.net> writes:
>>>
>>>> On 2025-03-15, Lawrence D'Oliveiro wrote:
>>>
>>>>> For example, are you allowed to put NTFS on a hot-pluggable volume?
>>>>> Somehow, I don’t think so.
>>>>
>>>> Practically every USB stick in existence would like to disagree.
>>>
>>> Those are usually FAT formatted. FAT32 or the newer exFAT. No issue
>>> reformatting to NTFS though.
>>>
>>> I've actually found NTFS on a USB SSD to be surprisingly widely
>>> supported on media players and TVs and such. I've used it on Android
>>> too. So NTFS has become my go-to portable FS.
>>
>> exFAT is better, but few TV sets support it, while many support NTFS.
>>
>
> EXFAT requires a license.
>
> NTFS requires a license.
>
> FAT32 requires a license (or at least TomTom may have discovered it did :-) )
>
I remember that, there was a court case.
> One difference is, some applications of EXFAT are
> covered by FRAND (where EXFAT is defined in a standards doc,
> as the default filesystem for a certain piece of hardware).
>
> In any case, whether license terms are fair and reasonable,
> or are the normal kind of license terms, equipment makers
> will not pay a penny more for licensing. It does not latter
> what the license fee is, they don't want to pay it, whatever it is.
Ah, I understand.
>
> NTFS is journaled. NTFS is slightly harder on a USB stick,
> from a wear perspective. You can improve the characteristics
> a tiny bit, by disabling "LastAccessed".
I did not know that.
> FAT32 and EXFAT are not journaled. You can set the cluster
> size on FAT32 and EXFAT (make it greater than or equal to
> the flash page size).
Similar to disabling the journal on ext4. And there is no licensing on it.
>
> BTFS
BTFS?
> supports extra large clusters, but the option is not
> backward compatible (a Win11 NTFS partition with one megabyte
> clusters, cannot be mounted by Windows XP, or by Windows 7).
> And that doesn't include testing the Linux response, as if
> an option isn't intended to be compatible, nobody is going to use it.
>
> Paul
Right.
--
Cheers,
Carlos E.R.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-17 23:19 +0000 |
| Message-ID | <vraamf$15c6f$2@dont-email.me> |
| In reply to | #81131 |
On Mon, 17 Mar 2025 22:04:12 +0100, Carlos E. R. wrote: > On 2025-03-17 20:21, Paul wrote: > >> BTFS > > BTFS? That’s the thing, Linux is so versatile, one of its supported filesystems is actually a K-Pop group.
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> |
|---|---|
| Date | 2025-03-19 16:45 +0200 |
| Message-ID | <sm0cyedt6xp.fsf@lakka.kapsi.fi> |
| In reply to | #81129 |
"Carlos E.R." <robin_listas@es.invalid> writes: > exFAT is better, but few TV sets support it, while many support NTFS. So how is exFAT better then? As a portable FS?
[toc] | [prev] | [next] | [standalone]
| From | ant@zimage.comANT (Ant) |
|---|---|
| Date | 2025-03-19 16:05 +0000 |
| Message-ID | <FDmdnS-41vuvdkf6nZ2dnZfqnPqdnZ2d@earthlink.com> |
| In reply to | #81138 |
Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
> "Carlos E.R." <robin_listas@es.invalid> writes:
> > exFAT is better, but few TV sets support it, while many support NTFS.
> So how is exFAT better then? As a portable FS?
exFAT can handle bigger files and partitions. FAT32 can't. See
https://duckduckgo.com/?q=exfat+vs.+fat32 for the details. Also, exFAT
is better for portabilities.
--
"The lips of the righteous nourish many, but fools die for lack of judgment." --Proverbs 10:21. Bruce Willis is 70, March Madness, & Doyers won 2 regular games in JP!
Note: A fixed width font (Courier, Monospace, etc.) is required to see this signature correctly.
/\___/\ Ant(Dude) @ http://aqfl.net & http://antfarm.home.dhs.org.
/ /\ /\ \ Please nuke ANT if replying by e-mail.
| |o o| |
\ _ /
( )
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-19 21:00 +0000 |
| Message-ID | <vrfb8k$1lo98$2@dont-email.me> |
| In reply to | #81139 |
On Wed, 19 Mar 2025 16:05:06 +0000, Ant wrote: > exFAT can handle bigger files and partitions. But it doesn’t offer the option for journalling to guard against filesystem corruption on crashes or improper removal/shutdown, does it.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-03-20 03:04 -0400 |
| Message-ID | <vrgelr$2n8fg$1@dont-email.me> |
| In reply to | #81142 |
On Wed, 3/19/2025 5:00 PM, Lawrence D'Oliveiro wrote: > On Wed, 19 Mar 2025 16:05:06 +0000, Ant wrote: > >> exFAT can handle bigger files and partitions. > > But it doesn’t offer the option for journalling to guard against > filesystem corruption on crashes or improper removal/shutdown, does it. > I bet most of the SD storage devices you've got in the house, were abused at one time or another, and how often do those get corrupted ? I don't have a lot of SDs, but I've been popping the one I've got in and out of equipment for years. Never once had an issue. FAT32. 32GB size. I think journaling is an excellent feature on a HDD or on an SSD (wear leveling). Journaling is a less good choice on an SD or on a USB flash stick (because the storage PHY isn't as sophisticated, and it is easier to burn a hole in those). If we could have flash sticks with SLC or MLC, my opinion might change then, but TLC or QLC devices are pretty sloppy pieces of crap. And those need static and dynamic wear leveling to give a good lifespan. I don't think I have any ExFAT partitions here at the moment. Usually, anything prepared that way, got paved over, through no fault of their own. Other file systems end up on the devices instead. Paul
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-20 22:02 +0000 |
| Message-ID | <vri39o$4qrh$2@dont-email.me> |
| In reply to | #81143 |
On Thu, 20 Mar 2025 03:04:27 -0400, Paul wrote: > If we could have flash sticks with SLC or MLC, my opinion might > change then, but TLC or QLC devices are pretty sloppy pieces of > crap. And those need static and dynamic wear leveling to give a good > lifespan. Speaking of which, Linux offers one or two filesystems which are specifically designed for use on such media, with wear-levelling built into the storage allocation algorithms themselves.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-21 11:50 +0100 |
| Message-ID | <3ssvalx2ng.ln2@Telcontar.valinor> |
| In reply to | #81150 |
On 2025-03-20 23:02, Lawrence D'Oliveiro wrote: > On Thu, 20 Mar 2025 03:04:27 -0400, Paul wrote: > >> If we could have flash sticks with SLC or MLC, my opinion might >> change then, but TLC or QLC devices are pretty sloppy pieces of >> crap. And those need static and dynamic wear leveling to give a good >> lifespan. > > Speaking of which, Linux offers one or two filesystems which are > specifically designed for use on such media, with wear-levelling built > into the storage allocation algorithms themselves. I remember one that was very promising, a four letter name that I have forgotten; but the support was removed in my distro (openSUSE) because the specs changed on every release of the distro, and a stick formatted one year would be unreadable the next year or something of the sort. It was industry designed for sticks and cards. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-21 12:21 +0100 |
| Message-ID | <imuvalx6sl.ln2@Telcontar.valinor> |
| In reply to | #81154 |
On 2025-03-21 11:50, Carlos E.R. wrote: > On 2025-03-20 23:02, Lawrence D'Oliveiro wrote: >> On Thu, 20 Mar 2025 03:04:27 -0400, Paul wrote: >> >>> If we could have flash sticks with SLC or MLC, my opinion might >>> change then, but TLC or QLC devices are pretty sloppy pieces of >>> crap. And those need static and dynamic wear leveling to give a good >>> lifespan. >> >> Speaking of which, Linux offers one or two filesystems which are >> specifically designed for use on such media, with wear-levelling built >> into the storage allocation algorithms themselves. > > > I remember one that was very promising, a four letter name that I have > forgotten; but the support was removed in my distro (openSUSE) because > the specs changed on every release of the distro, and a stick formatted > one year would be unreadable the next year or something of the sort. > > It was industry designed for sticks and cards. > f2fs -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-24 00:50 +0000 |
| Message-ID | <vrqa9i$3ko29$4@dont-email.me> |
| In reply to | #81156 |
On Fri, 21 Mar 2025 12:21:22 +0100, Carlos E.R. wrote: > On 2025-03-21 11:50, Carlos E.R. wrote: > >> On 2025-03-20 23:02, Lawrence D'Oliveiro wrote: >> >>> Speaking of which, Linux offers one or two filesystems which are >>> specifically designed for use on such media, with wear-levelling built >>> into the storage allocation algorithms themselves. >> >> I remember one that was very promising, a four letter name that I have >> forgotten; but the support was removed in my distro (openSUSE) because >> the specs changed on every release of the distro, and a stick formatted >> one year would be unreadable the next year or something of the sort. >> >> It was industry designed for sticks and cards. >> > f2fs I see it is supported in my current Debian Unstable 6.12.19 kernel. A quick search did not turn up any reports of version-incompatibility issues. Though the Arch Wiki <https://wiki.archlinux.org/title/F2FS> has a comprehensive list of usage tips as well as a pretty detailed version history. I see nilfs2 mentioned as another similar contender.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-24 14:23 +0100 |
| Message-ID | <ku28blxb1p.ln2@Telcontar.valinor> |
| In reply to | #81177 |
On 2025-03-24 01:50, Lawrence D'Oliveiro wrote: > On Fri, 21 Mar 2025 12:21:22 +0100, Carlos E.R. wrote: > >> On 2025-03-21 11:50, Carlos E.R. wrote: >> >>> On 2025-03-20 23:02, Lawrence D'Oliveiro wrote: >>> >>>> Speaking of which, Linux offers one or two filesystems which are >>>> specifically designed for use on such media, with wear-levelling built >>>> into the storage allocation algorithms themselves. >>> >>> I remember one that was very promising, a four letter name that I have >>> forgotten; but the support was removed in my distro (openSUSE) because >>> the specs changed on every release of the distro, and a stick formatted >>> one year would be unreadable the next year or something of the sort. >>> >>> It was industry designed for sticks and cards. >>> >> f2fs > > I see it is supported in my current Debian Unstable 6.12.19 kernel. A > quick search did not turn up any reports of version-incompatibility > issues. Though the Arch Wiki <https://wiki.archlinux.org/title/F2FS> has a > comprehensive list of usage tips as well as a pretty detailed version > history. > > I see nilfs2 mentioned as another similar contender. Archived-At: <https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/RJAFG564TR3ZYQSAJVJDSJPHDNPKPR35/> <https://wiki.archlinux.org/title/F2FS> Warning: The data contained on F2FS partitions can become unusable if the kernel version on the running machine is older than the kernel version used to create the partition. For example, this limitation can manifest if the F2FS partition was created on a mainline kernel provided by linux yet the system has a need to downgrade to an older series of kernels provided by linux-lts. See FS#69363. <https://www.reddit.com/r/openSUSE/comments/enlu5b/speaking_of_lack_of_f2fs_support_by_tumbleweed/> rbrownsuse • 5y ago Profile Badge for the Achievement Top 1% Commenter Top 1% Commenter I'm not sure I like the idea of a booting to a filesystem that is known to have very serious flaws, including no protection from causing the entire system from crashing if the kernel tries to mount a F2FS filesystem created in an older version of the kernel. Not only is that downright terrifying in general use (just wait till those Debian systems patch to a new version of F2FS..) but it's also a wonderful denial of service vector..use all the fancy USB or network hotplugability you can do with storage devices these days and watch as the kernel tries to mount invalid old F2FS filesystems and panic all systems.... Yeah..thanks but no thanks.. openSUSE is better off with F2FS disabled by default (See https://bugzilla.opensuse.org/show_bug.cgi?id=1109665 before arguing with this comment) ... xeq937 openSUSE doesn't support F2FS, unless you recompile the kernel manually, as far as I know. You might try exFAT with your phone and openSUSE instead. xeq937 • 5y ago You can either recompile openSUSE kernel (which is a tremendous pain and fraught with pitfalls), or use another distro. I'd go with the latter. Unfortunately openSUSE has some sort of vendetta against F2FS. ... mvribeiro • 5y ago Thank you! I think it will be compiled with the m option in the future, so that the module gets compiled so it works after disabling the blacklist. Let's see if it's there in the next kernel update. Edit: https://bugzilla.opensuse.org/show_bug.cgi?id=1173546 ... mvribeiro • 5y ago • Edited 5y ago No! It's still blacklisted. But after the next minor kernel update it may be possible to mount F2FS after simply removing the blacklist. This unreleased binary kernel rpm already has it: https://build.opensuse.org/package/binaries/Kernel:HEAD/kernel-default/standard I checked the contents of that x86_64.rpm and it does have a f2fs.ko.xz. I won't install it yet because I need nvidia for two screens, but shortly it'll probably be available on TW. Edit: This brown guy is worse than Linus. People shouldn't let him bark around out of his leash tarnishing the name of openSUSE devs. It's gross. Things got easier later. Archived-At: <https://lists.opensuse.org/archives/list/users@lists.opensuse.org/message/NYSLWKRMM65QY44GRG2RBOHND7EBAO5O/> Huh? bor@tw:~> /usr/sbin/modinfo f2fs filename: /usr/lib/modules/6.11.0-1-default/kernel/fs/f2fs/f2fs.ko.zst softdep: pre: crc32 license: GPL description: Flash Friendly File System ... suserelease: openSUSE Tumbleweed ... signer: openSUSE Secure Boot CA -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-20 12:24 +0100 |
| Message-ID | <nfatalxrg3.ln2@Telcontar.valinor> |
| In reply to | #81142 |
On 2025-03-19 22:00, Lawrence D'Oliveiro wrote: > On Wed, 19 Mar 2025 16:05:06 +0000, Ant wrote: > >> exFAT can handle bigger files and partitions. > > But it doesn’t offer the option for journalling to guard against > filesystem corruption on crashes or improper removal/shutdown, does it. Perfect. You do not want journalling on an usb stick or memory card. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-20 22:01 +0000 |
| Message-ID | <vri36u$4qrh$1@dont-email.me> |
| In reply to | #81146 |
On Thu, 20 Mar 2025 12:24:07 +0100, Carlos E.R. wrote: > On 2025-03-19 22:00, Lawrence D'Oliveiro wrote: >> >> On Wed, 19 Mar 2025 16:05:06 +0000, Ant wrote: >> >>> exFAT can handle bigger files and partitions. >> >> But it doesn’t offer the option for journalling to guard against >> filesystem corruption on crashes or improper removal/shutdown, does it. > > Perfect. > > You do not want journalling on an usb stick or memory card. But SSDs are also built on flash memory technology; do you disable journalling on those as well?
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-21 11:51 +0100 |
| Message-ID | <1vsvalx2ng.ln2@Telcontar.valinor> |
| In reply to | #81149 |
On 2025-03-20 23:01, Lawrence D'Oliveiro wrote: > On Thu, 20 Mar 2025 12:24:07 +0100, Carlos E.R. wrote: > >> On 2025-03-19 22:00, Lawrence D'Oliveiro wrote: >>> >>> On Wed, 19 Mar 2025 16:05:06 +0000, Ant wrote: >>> >>>> exFAT can handle bigger files and partitions. >>> >>> But it doesn’t offer the option for journalling to guard against >>> filesystem corruption on crashes or improper removal/shutdown, does it. >> >> Perfect. >> >> You do not want journalling on an usb stick or memory card. > > But SSDs are also built on flash memory technology; do you disable > journalling on those as well? No, they have wear levelling, and an expected lifetime with normal usage patterns that is quite long. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-03-21 10:16 -0400 |
| Message-ID | <vrjsb8$1nqfi$1@dont-email.me> |
| In reply to | #81153 |
On Fri, 3/21/2025 6:51 AM, Carlos E.R. wrote: > On 2025-03-20 23:01, Lawrence D'Oliveiro wrote: >> On Thu, 20 Mar 2025 12:24:07 +0100, Carlos E.R. wrote: >> >>> On 2025-03-19 22:00, Lawrence D'Oliveiro wrote: >>>> >>>> On Wed, 19 Mar 2025 16:05:06 +0000, Ant wrote: >>>> >>>>> exFAT can handle bigger files and partitions. >>>> >>>> But it doesn’t offer the option for journalling to guard against >>>> filesystem corruption on crashes or improper removal/shutdown, does it. >>> >>> Perfect. >>> >>> You do not want journalling on an usb stick or memory card. >> >> But SSDs are also built on flash memory technology; do you disable >> journalling on those as well? > > No, they have wear levelling, and an expected lifetime with normal usage patterns that is quite long. > Exactly. SSDs algorithm and processing power (I read of an SSD yesterday with a five core ARM processor in it), ensures that the entire wear life of the device (number of cells times cycles) is harvested. USB sticks don't even come remotely close to that. Some USB sticks, don't even seem to follow what technical information is available for them. Either their flash chips are entire crap (should have been thrown out at flash factory), or, something is very wrong with the controller. Paul
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-22 13:52 +0100 |
| Message-ID | <4eo2blx5q4.ln2@Telcontar.valinor> |
| In reply to | #81157 |
On 2025-03-21 15:16, Paul wrote: > On Fri, 3/21/2025 6:51 AM, Carlos E.R. wrote: >> On 2025-03-20 23:01, Lawrence D'Oliveiro wrote: >>> On Thu, 20 Mar 2025 12:24:07 +0100, Carlos E.R. wrote: >>> >>>> On 2025-03-19 22:00, Lawrence D'Oliveiro wrote: >>>>> >>>>> On Wed, 19 Mar 2025 16:05:06 +0000, Ant wrote: >>>>> >>>>>> exFAT can handle bigger files and partitions. >>>>> >>>>> But it doesn’t offer the option for journalling to guard against >>>>> filesystem corruption on crashes or improper removal/shutdown, does it. >>>> >>>> Perfect. >>>> >>>> You do not want journalling on an usb stick or memory card. >>> >>> But SSDs are also built on flash memory technology; do you disable >>> journalling on those as well? >> >> No, they have wear levelling, and an expected lifetime with normal usage patterns that is quite long. >> > > Exactly. SSDs algorithm and processing power (I read of an > SSD yesterday with a five core ARM processor in it), ensures > that the entire wear life of the device (number of cells times cycles) > is harvested. USB sticks don't even come remotely close to that. Some > USB sticks, don't even seem to follow what technical information > is available for them. Either their flash chips are entire crap > (should have been thrown out at flash factory), or, something > is very wrong with the controller. I just realized I have an nvme with 72713 hours of use. Probably the first one I bought. === START OF INFORMATION SECTION === Model Family: SandForce Driven SSDs Device Model: KINGSTON SMS200S3120G Serial Number: ... LU WWN Device Id: 5 0026b7 26901494e Firmware Version: 608ABBF0 User Capacity: 120,034,123,776 bytes [120 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device TRIM Command: Available Device is: In smartctl database 7.3/5528 ATA Version is: ATA8-ACS, ACS-2 T13/2015-D revision 3 SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Sat Mar 22 13:14:02 2025 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled ... SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x0032 095 095 050 Old_age Always - 0/38481593 5 Retired_Block_Count 0x0033 100 100 003 Pre-fail Always - 0 9 Power_On_Hours_and_Msec 0x0032 017 017 000 Old_age Always - 72713h+43m+19.000s 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 184 171 Program_Fail_Count 0x000a 100 100 000 Old_age Always - 0 172 Erase_Fail_Count 0x0032 100 100 000 Old_age Always - 0 174 Unexpect_Power_Loss_Ct 0x0030 000 000 000 Old_age Offline - 134 177 Wear_Range_Delta 0x0000 000 000 000 Old_age Offline - 1 181 Program_Fail_Count 0x000a 100 100 000 Old_age Always - 0 182 Erase_Fail_Count 0x0032 100 100 000 Old_age Always - 0 187 Reported_Uncorrect 0x0012 100 100 000 Old_age Always - 0 189 Airflow_Temperature_Cel 0x0000 045 113 000 Old_age Offline - 45 (Min/Max 0/113) 194 Temperature_Celsius 0x0022 045 113 000 Old_age Always - 45 (Min/Max 0/113) 195 ECC_Uncorr_Error_Count 0x001c 120 120 000 Old_age Offline - 0/38481593 196 Reallocated_Event_Count 0x0033 100 100 003 Pre-fail Always - 0 201 Unc_Soft_Read_Err_Rate 0x001c 120 120 000 Old_age Offline - 0/38481593 204 Soft_ECC_Correct_Rate 0x001c 120 120 000 Old_age Offline - 0/38481593 230 Life_Curve_Status 0x0013 100 100 000 Pre-fail Always - 100 231 SSD_Life_Left 0x0000 094 094 011 Old_age Offline - 34359738368 233 SandForce_Internal 0x0032 000 000 000 Old_age Always - 40546 234 SandForce_Internal 0x0032 000 000 000 Old_age Always - 14524 241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always - 14524 242 Lifetime_Reads_GiB 0x0032 000 000 000 Old_age Always - 8232 244 Unknown_Attribute 0x0000 090 090 010 Old_age Offline - 20906303 I just run a short test, but it doesn't show - or they count hours differently: SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 7178 - # 2 Extended offline Completed without error 00% 7168 - # 3 Short offline Completed without error 00% 7166 - -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | alt.os.linux
csiph-web