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 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-03-22 14:18 -0400 |
| Message-ID | <vrmuto$ghug$1@dont-email.me> |
| In reply to | #81163 |
On Sat, 3/22/2025 8:52 AM, Carlos E.R. wrote: > 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 - That's amazing, that a 120GB drive is still alive. Some of those die due to firmware issues. it could be a SATA type NVME, rather than a PCIe. The entry in /dev should help you identify what it is listed under. As far as I know, Sandforce did compressing controllers for SATA, and Kingston was their major customer. I could not tell you whether Sandforce was still in business or not. Paul
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-22 23:20 +0100 |
| Message-ID | <hmp3blxg2o.ln2@Telcontar.valinor> |
| In reply to | #81168 |
On 2025-03-22 19:18, Paul wrote: > On Sat, 3/22/2025 8:52 AM, Carlos E.R. wrote: >> 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 ... >> 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 - > > That's amazing, that a 120GB drive is still alive. Some of those > die due to firmware issues. Oh. > it could be a SATA type NVME, rather than a PCIe. This one has the small connector directly on the PCB. The first one I saw. But the interesting thing is that it identifies as /dev/sda, not /dev/nvme0n1 > > The entry in /dev should help you identify what it is listed under. Ah. Well, /dev/sda. > > As far as I know, Sandforce did compressing controllers for SATA, > and Kingston was their major customer. I could not tell you > whether Sandforce was still in business or not. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-24 23:20 +0000 |
| Message-ID | <vrspc1$1v6cu$1@dont-email.me> |
| In reply to | #81153 |
On Fri, 21 Mar 2025 11:51:45 +0100, Carlos E.R. wrote: > On 2025-03-20 23:01, Lawrence D'Oliveiro wrote: > >> 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. Fun fact: SSDs at a low level resemble what’s called a “log-structured” filesystem. This is what happens when you have a filesystem that is all journal, getting rid of the conventional filesystem part altogether.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-25 12:55 +0100 |
| Message-ID | <s5iablxi7i.ln2@Telcontar.valinor> |
| In reply to | #81182 |
On 2025-03-25 00:20, Lawrence D'Oliveiro wrote: > On Fri, 21 Mar 2025 11:51:45 +0100, Carlos E.R. wrote: > >> On 2025-03-20 23:01, Lawrence D'Oliveiro wrote: >> >>> 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. > > Fun fact: SSDs at a low level resemble what’s called a “log-structured” > filesystem. This is what happens when you have a filesystem that is all > journal, getting rid of the conventional filesystem part altogether. Interesting. That could be used to design a different filesystem, perhaps. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-26 00:27 +0000 |
| Message-ID | <vrvhle$gce5$1@dont-email.me> |
| In reply to | #81184 |
On Tue, 25 Mar 2025 12:55:08 +0100, Carlos E.R. wrote: > On 2025-03-25 00:20, Lawrence D'Oliveiro wrote: >> >> On Fri, 21 Mar 2025 11:51:45 +0100, Carlos E.R. wrote: >> >>> On 2025-03-20 23:01, Lawrence D'Oliveiro wrote: >>> >>>> 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. >> >> Fun fact: SSDs at a low level resemble what’s called a “log-structured” >> filesystem. This is what happens when you have a filesystem that is all >> journal, getting rid of the conventional filesystem part altogether. > > Interesting. > > That could be used to design a different filesystem, perhaps. Note the point, though: the journal itself provides the wear-levelling.
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> |
|---|---|
| Date | 2025-03-20 11:07 +0200 |
| Message-ID | <sm04izot6hy.fsf@lakka.kapsi.fi> |
| In reply to | #81139 |
ant@zimage.comANT (Ant) writes: > 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. Wow, way to go off on a weird tangent. I specifically wanted Carlos to explain why he thinks exFAT is better than NTFS for portability since he seemed to contradict himself, saying, as he did, that "few TV sets support it". Carlos' answer was, apparently, "yes".
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-20 12:29 +0100 |
| Message-ID | <kpatalxvu3.ln2@Telcontar.valinor> |
| In reply to | #81145 |
On 2025-03-20 10:07, Anssi Saari wrote: > ant@zimage.comANT (Ant) writes: > >> 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. > > Wow, way to go off on a weird tangent. I specifically wanted Carlos to > explain why he thinks exFAT is better than NTFS for portability since he > seemed to contradict himself, saying, as he did, that "few TV sets > support it". > > Carlos' answer was, apparently, "yes". exFAT is better that NTFS on removable flash media such as sticks or memory cards, because it was designed for that usage. It is better than NTFS or FAT for exchanging files between Windows and Linux (because it is really supported on Linux, and supports large files). However, being better is pointless if the destination machine does not support it. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-03-19 14:14 -0400 |
| Message-ID | <vrf1i3$1dnht$1@dont-email.me> |
| In reply to | #81138 |
On Wed, 3/19/2025 10:45 AM, Anssi Saari 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? > It is FAT32 with large clusters and larger allowed number of files. https://en.wikipedia.org/wiki/ExFAT It may have been added to WinXP as an IFS (Installable File System, like a FUSE but for Windows). Paul
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-19 21:18 +0100 |
| Message-ID | <1elralx69s.ln2@Telcontar.valinor> |
| In reply to | #81138 |
On 2025-03-19 15:45, Anssi Saari 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? Yes, if your destination machine supports it. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> |
|---|---|
| Date | 2025-03-20 10:51 +0200 |
| Message-ID | <sm08qp0t78g.fsf@lakka.kapsi.fi> |
| In reply to | #81141 |
"Carlos E.R." <robin_listas@es.invalid> writes: > On 2025-03-19 15:45, Anssi Saari 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? > > Yes, if your destination machine supports it. Yes? I asked how and you answer yes?
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-20 12:22 +0100 |
| Message-ID | <fdatalxrg3.ln2@Telcontar.valinor> |
| In reply to | #81144 |
On 2025-03-20 09:51, Anssi Saari wrote: > "Carlos E.R." <robin_listas@es.invalid> writes: > >> On 2025-03-19 15:45, Anssi Saari 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? >> >> Yes, if your destination machine supports it. > > Yes? I asked how and you answer yes? I don't understand what "how" means in this context. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | TJ <TJ@noneofyour.business> |
|---|---|
| Date | 2025-03-20 20:35 -0400 |
| Message-ID | <vric88$b3ri$1@dont-email.me> |
| In reply to | #81141 |
On 2025-03-19 16:18, Carlos E.R. wrote: > On 2025-03-19 15:45, Anssi Saari 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? > > Yes, if your destination machine supports it. > Ay, there's the rub. I have a ATSC->NTSC TV converter that has a usb port and a PVR function. It can also play various formats of video files from a device in that port. It can work with FAT32 or NTFS. That's it. No exceptions. ExFAT would probably work better, if only it supported it. TJ
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-03-21 11:55 +0100 |
| Message-ID | <66tvalx2ng.ln2@Telcontar.valinor> |
| In reply to | #81151 |
On 2025-03-21 01:35, TJ wrote: > On 2025-03-19 16:18, Carlos E.R. wrote: >> On 2025-03-19 15:45, Anssi Saari 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? >> >> Yes, if your destination machine supports it. >> > Ay, there's the rub. > > I have a ATSC->NTSC TV converter that has a usb port and a PVR function. > It can also play various formats of video files from a device in that > port. It can work with FAT32 or NTFS. That's it. No exceptions. > > ExFAT would probably work better, if only it supported it. Exactly my problem. On the other hand, I find that TV sets support for playing media is terrible. Some cases they do not support subtitles aka captions, others the forward/backwards keys are so slow as being unusable. So I end by having an old laptop permanently attached to the TV. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Joerg Walther <joerg.walther@magenta.de> |
|---|---|
| Date | 2025-03-21 16:24 +0100 |
| Message-ID | <801rtjhgoj3blh0517recp50ul2hkiqv6m@joergwalther.my-fqdn.de> |
| In reply to | #81155 |
Carlos E.R. wrote: >On the other hand, I find that TV sets support for playing media is >terrible. Some cases they do not support subtitles aka captions, others >the forward/backwards keys are so slow as being unusable. So I end by >having an old laptop permanently attached to the TV. I use a Raspberry Pi with Libreelec for this, this probably is the best media center around, it can even download subtitles while watching and it plays every file I throw at it. An old Windows Media Center remote worked out of the box, which came very handy. -jw- -- And now for something completely different...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-22 06:58 +0000 |
| Message-ID | <vrln1v$3di74$3@dont-email.me> |
| In reply to | #81158 |
On Fri, 21 Mar 2025 16:24:11 +0100, Joerg Walther wrote: > An old Windows Media Center remote worked out of the box, which came > very handy. What happened to Windows Media Center? Killed off by Linux.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-03-22 04:29 -0400 |
| Message-ID | <vrlsd8$3ifdv$1@dont-email.me> |
| In reply to | #81161 |
On Sat, 3/22/2025 2:58 AM, Lawrence D'Oliveiro wrote: > On Fri, 21 Mar 2025 16:24:11 +0100, Joerg Walther wrote: > >> An old Windows Media Center remote worked out of the box, which came >> very handy. > > What happened to Windows Media Center? > > Killed off by Linux. > Uh, not really. when it comes to "continuity" on high tech fluff, the bean counters hate "third party expense". For example, even if an MPEG2 license from MPEG-LA costs a dollar a node, that's a "whoa! hold on there" issue for the bean counters at Microsoft. They want a counter-balancing income if you do that. Right now on Windows, it needs a HEVC license from the Microsoft Store, so that HEIC can be decoded. Rather than Microsoft pay that out of their own pocket, you buy the item from the Microsoft Store, and that gives you the CODEC needed. If they didn't do that, they'd be sued. Linux doesn't get sued, because they are giving away the software and not making money from it. the Linux overhead expense is different. As "compensation" for Media Center, for a short time, on the next OS where Media Center was discontinued, you were given two MPEG2 CODECS "for free". To Microsoft then, that represented the "value" to them, of the removed software. Another expense for Media Center, was the Guide Data feed per user. Linux doesn't have Guide Data. Professional Guide Data always costs money. You can license Guide Data from a TV Network, for around $50K per annum. Then, you chop that up, and bill individual customers, to make your $50K back. When Guide Data sources go out of business, it's because they could not sell enough units at $25 per year. Microsoft was paying someone else for the Guide Data, while Media Center was available. I used to have Guide Data downloads every day on the Test Machine (which was running Media Center for a while as a demo, so I could note the missing bits in USENET posts). For example, in Canada, the digital TV side of Media Center, did not work, unless you got some files from a private citizen in Canada, who had figured out how to fix it. That's how I got mine running. Media Center sank under its own weight. Linux had nothing to do with the business decisions (overhead costs). If you buy the WinTV software from Hauppauge, that's another way to record TV programs. I don't know if the Guide Data for that still works or not. Paul
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-22 22:00 +0000 |
| Message-ID | <vrnbtc$rkfk$3@dont-email.me> |
| In reply to | #81162 |
On Sat, 22 Mar 2025 04:29:28 -0400, Paul wrote: > On Sat, 3/22/2025 2:58 AM, Lawrence D'Oliveiro wrote: >> >> What happened to Windows Media Center? >> >> Killed off by Linux. >> > Uh, not really. > > Right now on Windows, it needs a HEVC license from the Microsoft Store, > so that HEIC can be decoded. Rather than Microsoft pay that out of their > own pocket, you buy the item from the Microsoft Store, and that gives > you the CODEC needed. If they didn't do that, they'd be sued. > > Linux doesn't get sued, because they are giving away the software and > not making money from it. the Linux overhead expense is different. > > As "compensation" for Media Center, for a short time, > on the next OS where Media Center was discontinued, > you were given two MPEG2 CODECS "for free". To Microsoft then, that > represented the "value" to them, of the removed software. > > Another expense for Media Center, was the Guide Data feed per user. > Linux doesn't have Guide Data. Professional Guide Data always costs > money. Funny, you said Windows Media Center wasn’t killed by Linux, and then go on to list a long catalogue of reasons why it was.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-03-23 02:01 -0400 |
| Message-ID | <vro83p$1nt1f$1@dont-email.me> |
| In reply to | #81170 |
On Sat, 3/22/2025 6:00 PM, Lawrence D'Oliveiro wrote: > > Funny, you said Windows Media Center wasn’t killed by Linux, and then go > on to list a long catalogue of reasons why it was. > It wasn't killed by linus, it was killed by overhead cost. If it was costing them nothing (no bills coming in for MPEG-LA licenses or no bill for Guide Data), then it would still be available today. A similar thing happened to the NVidia chipset that had five DSP cores in the Southbridge. One of the cores did AC3 encoding with low latency. A great little toy, for some people with SPDIF connected AV receivers. Well, that did not get included in the very next chipset, and the reason, was the license cost per chip (even if the customer wasn't using the feature, the AC3 license had to be paid). So the DSP feature wasn't used any more. Any time there is a "line-item expense" associated with an activity, a bean counter will stop it. That's how business works. As the product manager, you have to show the bean counter, how you are making the money back in some way. And one of the schemes for that, is to make the customer buy the license when they want one (from a thing such as an online Store). On the first generation of a product idea, you can write "Promotional cost" next to the line item, for its year of introduction. But after a product is mature, you have to justify every line-item expense. And that's how your product gets canceled. Paul
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-03-24 00:43 +0000 |
| Message-ID | <vrq9rg$3ko29$3@dont-email.me> |
| In reply to | #81174 |
On Sun, 23 Mar 2025 02:01:29 -0400, Paul wrote: > On Sat, 3/22/2025 6:00 PM, Lawrence D'Oliveiro wrote: > >> Funny, you said Windows Media Center wasn’t killed by Linux, and then >> go on to list a long catalogue of reasons why it was. >> > It wasn't killed by linu[x], it was killed by overhead cost. Another area in which Linux had the advantage, and was able to take over the market thereby. You just keep coming up with more and more reasons why my point stands.
[toc] | [prev] | [next] | [standalone]
| From | TJ <TJ@noneofyour.business> |
|---|---|
| Date | 2025-03-21 16:37 -0400 |
| Message-ID | <vrkilm$290j4$2@dont-email.me> |
| In reply to | #81155 |
On 2025-03-21 06:55, Carlos E.R. wrote: > On 2025-03-21 01:35, TJ wrote: >> On 2025-03-19 16:18, Carlos E.R. wrote: >>> On 2025-03-19 15:45, Anssi Saari 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? >>> >>> Yes, if your destination machine supports it. >>> >> Ay, there's the rub. >> >> I have a ATSC->NTSC TV converter that has a usb port and a PVR >> function. It can also play various formats of video files from a >> device in that port. It can work with FAT32 or NTFS. That's it. No >> exceptions. >> >> ExFAT would probably work better, if only it supported it. > > Exactly my problem. > > On the other hand, I find that TV sets support for playing media is > terrible. Some cases they do not support subtitles aka captions, others > the forward/backwards keys are so slow as being unusable. So I end by > having an old laptop permanently attached to the TV. > I have My converter box in my bedroom, playing through an old Commodore 1701 monitor. Better resolution than an analog TV set of that era, but not as good as HD. Used to belong to an Atari User Group for use with their 8-bit computers. There was a time, back in the day, when I was an Atari XL/XE power user. My XE had been upgraded to have a whole 320KB of RAM. It was a simpler time... I miss subtitles sometimes, but not very much. For my purposes, as long as the video is as watchable as what I had with my old NTSC TV, I'm happy. TJ
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | alt.os.linux
csiph-web