Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mobile.android > #36869 > unrolled thread

Android 6

Back to article view | Back to comp.mobile.android

Contents

  Android 6 Bill <Billaboard@gmail.com> - 2016-12-22 17:21 +0000
    Re: Android 6 The Real Bev <bashley101@gmail.com> - 2016-12-22 10:00 -0800
      Re: Android 6 Bill <Billaboard@gmail.com> - 2016-12-23 00:23 +0000
        Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-22 19:30 -0500
          Re: Android 6 Bill <Billaboard@gmail.com> - 2016-12-23 12:42 +0000
            Re: Android 6 tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2016-12-23 11:58 -0500
              Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-29 13:43 +0100
                Re: Android 6 Daniel James <daniel@me.invalid> - 2016-12-30 15:34 +0000
                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-30 22:33 +0100
                    Re: Android 6 Daniel James <daniel@me.invalid> - 2016-12-31 13:27 +0000
                      Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-04 08:59 +0100
                        Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-04 13:40 +0000
                          Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-11 09:00 +0100
                            Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-15 18:23 +0000
                              Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-15 21:20 +0100
                        Re: Android 6 AL <45364747@invalid.com> - 2017-01-04 10:06 -0700
                          Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-11 09:00 +0100
                        Re: Android 6 tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2017-01-05 01:34 -0500
                          Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-07 14:14 +0000
                            Re: Android 6 tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2017-01-07 13:09 -0500
                              Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-08 18:18 +0000
                                Re: Android 6 tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2017-01-08 15:42 -0500
                                  Re: Android 6 The Real Bev <bashley101@gmail.com> - 2017-01-08 17:11 -0800
                                    Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-08 20:19 -0500
                                  Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-09 23:55 +0000
                                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-11 18:07 +0100
                                Re: Android 6 Frank Slootweg <this@ddress.is.invalid> - 2017-01-08 21:34 +0000
                                  Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-09 23:55 +0000
            Re: Android 6 Joerg Lorenz <hugybear@gmx.ch> - 2016-12-24 10:49 +0100
    Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-22 23:55 +0100
      Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-22 19:15 -0500
        Re: Android 6 Joerg Lorenz <hugybear@gmx.ch> - 2016-12-23 05:46 +0100
          Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-23 00:15 -0500
        Re: Android 6 Dave Higton <dave@davehigton.me.uk> - 2016-12-23 17:11 +0000
          Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-23 12:43 -0500
            Re: Android 6 Dave Higton <dave@davehigton.me.uk> - 2016-12-23 21:22 +0000
              Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-24 14:29 -0500
                Re: Android 6 Dave Higton <dave@davehigton.me.uk> - 2016-12-25 11:10 +0000
                  Re: Android 6 Piet <www.godfatherof.nl/@opt-in.invalid> - 2016-12-25 12:37 +0100
                  Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-25 11:18 -0500
                    Re: Android 6 Dave Higton <dave@davehigton.me.uk> - 2016-12-25 20:28 +0000
            Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-29 12:02 -0500
              Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-29 23:45 +0100
                Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-29 18:02 -0500
                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-30 22:24 +0100
                    Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-31 11:55 -0500
                      Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-04 09:04 +0100
                        Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-04 10:14 -0500
                          Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-11 18:11 +0100
                            Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-11 13:05 -0500
                              Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-13 17:23 +0100
                                Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-16 15:35 -0500
                                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-17 05:39 +0100
                Re: Android 6 Daniel James <daniel@me.invalid> - 2016-12-30 15:34 +0000
                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-30 22:26 +0100
                    Re: Android 6 Daniel James <daniel@me.invalid> - 2016-12-31 13:27 +0000
                      Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-31 11:55 -0500
                      Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-04 09:11 +0100
                        Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-04 13:40 +0000
                        Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-04 10:14 -0500
                          Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-11 18:12 +0100
                            Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-11 13:05 -0500
                              Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-13 17:24 +0100
                                Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-15 18:23 +0000
                                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-15 21:30 +0100
                                    Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-16 15:42 +0000
                                Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-16 15:35 -0500
                                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-17 05:44 +0100
                                  Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-17 17:47 +0000
                  Re: Android 6 Bill <Billaboard@gmail.com> - 2017-01-01 01:05 +0000
                    Re: Android 6 tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2017-01-02 02:08 -0500
                      Re: Android 6 David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2017-01-02 08:01 +0000
                      Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-02 08:51 -0500
                      Re: Android 6 Bill <Billaboard@gmail.com> - 2017-01-02 20:41 +0000
                      Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-04 09:18 +0100
                    Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-04 09:14 +0100
            Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-29 14:05 +0100
        Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-29 12:02 -0500
          Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-29 23:46 +0100
            Re: Android 6 Dave Higton <dave@davehigton.me.uk> - 2016-12-31 20:18 +0000
        Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-29 13:47 +0100

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#37668

nospam wrote:

> In article <26aa4a1e-1283-465b-010d-f0d53655763e@arnowelzel.de>, Arno
> Welzel <usenet@arnowelzel.de> wrote:
[...]
>> Flash memory may get slower when *writing* a lot of data, because of
>> wear leveling more blocks get written at least once and have to be
>> erased before you write something. Exactly this is, what TRIM does:
>> erasing unused blocks in the background, so they are ready when you need
>> them.
> 
> negligible, if at all.

You call a factor of 2 or more "negligible"? SSDs lose about 50% speed
over time without TRIM.


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37671

In article <6c4edf24-6085-bebe-504d-8b3458643c2a@arnowelzel.de>, Arno
Welzel <usenet@arnowelzel.de> wrote:

> >> Flash memory may get slower when *writing* a lot of data, because of
> >> wear leveling more blocks get written at least once and have to be
> >> erased before you write something. Exactly this is, what TRIM does:
> >> erasing unused blocks in the background, so they are ready when you need
> >> them.
> > 
> > negligible, if at all.
> 
> You call a factor of 2 or more "negligible"? SSDs lose about 50% speed
> over time without TRIM.

no they absolutely do not. complete bullshit.

[toc] | [prev] | [next] | [standalone]

#37711

nospam wrote:

> In article <6c4edf24-6085-bebe-504d-8b3458643c2a@arnowelzel.de>, Arno
> Welzel <usenet@arnowelzel.de> wrote:
> 
>>>> Flash memory may get slower when *writing* a lot of data, because of
>>>> wear leveling more blocks get written at least once and have to be
>>>> erased before you write something. Exactly this is, what TRIM does:
>>>> erasing unused blocks in the background, so they are ready when you need
>>>> them.
>>>
>>> negligible, if at all.
>>
>> You call a factor of 2 or more "negligible"? SSDs lose about 50% speed
>> over time without TRIM.
> 
> no they absolutely do not. complete bullshit.

They do. That's why TRIM was invented. Why should one invent something
like TRIM if it doesn't matter if blocks have to be erased before
writing on them?


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37752

In article <4b02037a-1aeb-9f8d-251c-4b525fc330f8@arnowelzel.de>, Arno 
Welzel wrote:
> That's why TRIM was invented.

Not really. TRIM was invented to enable the filesystem to communicate 
information about deleted/truncated files to the flash controller so 
that it could perform wear levelling more effectively and so prolong 
the life of the SSD. The importance of TRIM for speed is minor.

-- 
Cheers,
 Daniel.
 

[toc] | [prev] | [next] | [standalone]

#37755

Daniel James wrote:

> In article <4b02037a-1aeb-9f8d-251c-4b525fc330f8@arnowelzel.de>, Arno 
> Welzel wrote:
>> That's why TRIM was invented.
> 
> Not really. TRIM was invented to enable the filesystem to communicate 
> information about deleted/truncated files to the flash controller so 
> that it could perform wear levelling more effectively and so prolong 
> the life of the SSD. The importance of TRIM for speed is minor.

I don't agree. See:

<http://www.anandtech.com/show/2738>
<http://www.anandtech.com/show/2738/8>
<http://www.anandtech.com/show/2738/10>

<https://en.wikipedia.org/wiki/Trim_(computing)>

-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37764

In article <6fc6ac75-2e6c-b09a-d8dd-23b185b02217@arnowelzel.de>, Arno 
Welzel wrote:
>> TRIM was invented to enable the filesystem to communicate 
>> information about deleted/truncated files to the flash controller so 
>> that it could perform wear levelling more effectively and so prolong 
>> the life of the SSD. The importance of TRIM for speed is minor.
> 
> I don't agree. See:
> 
> <http://www.anandtech.com/show/2738>
> <http://www.anandtech.com/show/2738/8>
> <http://www.anandtech.com/show/2738/10>
> 
> <https://en.wikipedia.org/wiki/Trim_(computing)>

Those references agree with what I said about what TRIM does, and 
emphasise (I would say over-emphasise) the fact that this will, in 
general, result in faster write times for an SSD that supports TRIM.

My point was that the original impetus for the implementation of TRIM 
had nothing (directly) to do with speed. SSD manufacturers wanted to use 
cheaper forms of flash memory (MLC rather than SLC, for example) and 
smaller flash cells to create high-capacity SSDs at affordable prices, 
but the cheaper and denser forms of flash could not support as many 
erase cycles as the flash memory that was then in use. 

In order to produce large SSDs with acceptable lifetimes while using 
inexpensive flash memory it was necessary to introduce wear levelling 
into the flash controller chips. The better the wear levelling is, the 
longer the SSD will last for a given type of flash memory (or, to put it 
another way, the better the wear levelling is the cheaper the flash 
memory can be for an SSD with a given expected life). TRIM technology 
enables the wear levelling to be more effective because the controller 
has more timely information about flash memory blocks that can be 
erased, and so is a crucial technology for extending the lifetimes of 
flash memory devices.

Yes, TRIM also makes flash devices faster, in general, and this is the 
advantage most evident to the end user. Speed is not the reason that 
TRIM was first introduced, though. That was done to make it possible to 
produce SSDs more cheaply by using cheaper forms of flash without 
compromising the lifetime of the SSDs.

In fact, all SSDs are so stupidly quick compared with spinning rust that 
the speed difference given by TRIM is hardly noticeable. It's not about 
speed it's about cost.

-- 
Cheers,
 Daniel.
 

[toc] | [prev] | [next] | [standalone]

#37767

In article <4b02037a-1aeb-9f8d-251c-4b525fc330f8@arnowelzel.de>, Arno
Welzel <usenet@arnowelzel.de> wrote:

> >>>> Flash memory may get slower when *writing* a lot of data, because of
> >>>> wear leveling more blocks get written at least once and have to be
> >>>> erased before you write something. Exactly this is, what TRIM does:
> >>>> erasing unused blocks in the background, so they are ready when you need
> >>>> them.
> >>>
> >>> negligible, if at all.
> >>
> >> You call a factor of 2 or more "negligible"? SSDs lose about 50% speed
> >> over time without TRIM.
> > 
> > no they absolutely do not. complete bullshit.
> 
> They do. That's why TRIM was invented. Why should one invent something
> like TRIM if it doesn't matter if blocks have to be erased before
> writing on them?

trim came to be when the firmware on ssds were primitive. that hasn't
been the case in *years*. ssds garbage collect on their own now and
have for a long time, making trim nice to have but *not* required.

the fact is that ssds do *not* lose 50% speed in a few years. absolute
bullshit, as anyone who has had an ssd for a while can attest.

[toc] | [prev] | [next] | [standalone]

#37774

nospam wrote:

[...]
> the fact is that ssds do *not* lose 50% speed in a few years. absolute
> bullshit, as anyone who has had an ssd for a while can attest.

"Bullshit"... aha...

<http://www.howtogeek.com/165542/why-solid-state-drives-slow-down-as-you-fill-them-up/>

Yes - modern SSDs with garbage collection etc. don't have this problem
any longer. But to say it is "bullshit" that this problem exists is
bullshit ;-).


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37795

In article <160120171535315385%nospam@nospam.invalid>, Nospam wrote:
> trim came to be when the firmware on ssds were primitive. that hasn't
> been the case in *years*. ssds garbage collect on their own now and
> have for a long time, making trim nice to have but *not* required.

That's not correct. All TRIM does is provide information to the flash 
controller so that it can garbage collect more efficiently. If there 
were no garbage collection process there would be no point in providing 
TRIM.

TRIM certainly isn't *required* for an SSD to operate, but if TRIM is 
implemented (on the SSD and in the filesystem driver) the wear 
levelling/garbage collection process of the SSD can maximize the SSD's 
life (and, yes, make it a bit faster too).

-- 
Cheers,
 Daniel.
 

[toc] | [prev] | [next] | [standalone]

#37115

In message <VA.00000c22.00519969@me.invalid>, Daniel James 
<daniel@me.invalid> writes
>What is more of a worry is the failure mode when the flash does begin 
>to fail. Ideally the whole device would just become read-only so that 
>no data would be lost, but one hears of more severe failures with no 
>data recoverable, which is a worry. I suspect that this is more likely 
>with SD cards than with SATA etc SSDs, as the controllers are 
>necessarily less sophisticated.
As the OP and as this has gone slightly OT, what is the reason why it is 
often recommended that SD cards in dashcams be regularly formatted in 
the dashcam?

In my case, the new 64GB and 128GB SD cards showed in W7 as being 
formatted  FAT32.They weren't initially recognised in the cam.

Formatted in the cam and they were recognised and work well.

When W7 displays their properties, they are both still shown as 
formatted FAT32.
-- 
Bill

[toc] | [prev] | [next] | [standalone]

#37147

> As the OP and as this has gone slightly OT, what is the reason why it is 
> often recommended that SD cards in dashcams be regularly formatted in 
> the dashcam?
> 
> In my case, the new 64GB and 128GB SD cards showed in W7 as being 
> formatted  FAT32.They weren't initially recognised in the cam.
> 
> Formatted in the cam and they were recognised and work well.
> 
> When W7 displays their properties, they are both still shown as 
> formatted FAT32.

When I format a *SD card with the help of a Windows system, there's no file
or folder to be found on the freshly formatted card.

When I use a particular non-Windows device to format the card, there's
often one (or several) specifically named folder(s) on the freshly
formatted card. For example, if it's a camera (or a phone with camera)
doing the formatting, there's often a DCIM folder created, along with a
Camera (or similarly named) subfolder, purpose-built for the use of the
device doing the formatting.

It might be (but no guarantees here) that, without those idiosyncratic
folders, the device won't recognize the card. HTH. Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

#37150

On 02/01/2017 07:08, tlvp wrote:
[]
> When I format a *SD card with the help of a Windows system, there's no file
> or folder to be found on the freshly formatted card.
[]

If you check for hidden or system files on the SD card, do you still see 
"no file or folder"?

-- 
Cheers,
David
Web: http://www.satsignal.eu

[toc] | [prev] | [next] | [standalone]

#37168

In article <77u3dhr8hkrv.jdtu6ks2qz3d$.dlg@40tude.net>, tlvp
<mPiOsUcB.EtLlLvEp@att.net> wrote:

> > As the OP and as this has gone slightly OT, what is the reason why it is 
> > often recommended that SD cards in dashcams be regularly formatted in 
> > the dashcam?
> > 
> > In my case, the new 64GB and 128GB SD cards showed in W7 as being 
> > formatted  FAT32.They weren't initially recognised in the cam.
> > 
> > Formatted in the cam and they were recognised and work well.
> > 
> > When W7 displays their properties, they are both still shown as 
> > formatted FAT32.
> 
> When I format a *SD card with the help of a Windows system, there's no file
> or folder to be found on the freshly formatted card.
> 
> When I use a particular non-Windows device to format the card, there's
> often one (or several) specifically named folder(s) on the freshly
> formatted card. For example, if it's a camera (or a phone with camera)
> doing the formatting, there's often a DCIM folder created, along with a
> Camera (or similarly named) subfolder, purpose-built for the use of the
> device doing the formatting.
> 
> It might be (but no guarantees here) that, without those idiosyncratic
> folders, the device won't recognize the card. HTH. Cheers, -- tlvp

cameras will write a dcim folder if there isn't one already there.

[toc] | [prev] | [next] | [standalone]

#37182

In message <77u3dhr8hkrv.jdtu6ks2qz3d$.dlg@40tude.net>, tlvp 
<mPiOsUcB.EtLlLvEp@att.net> writes
>When I use a particular non-Windows device to format the card, there's 
>often one (or several) specifically named folder(s) on the freshly 
>formatted card. For example, if it's a camera (or a phone with camera) 
>doing the formatting, there's often a DCIM folder created, along with a 
>Camera (or similarly named) subfolder, purpose-built for the use of the 
>device doing the formatting.
>
>It might be (but no guarantees here) that, without those idiosyncratic 
>folders, the device won't recognize the card.

This probably is the case, and I should have thought of it, but the 
camera in question doesn't have any way that I know of to interrupt  the 
process between formatting and starting the videoing process. So I have 
no way of checking.

There is also the question of why it seems to be recommended that these 
camera sd cards be reformatted in the camera on a regular basis.

-- 
Bill

[toc] | [prev] | [next] | [standalone]

#37281

tlvp wrote:

[...]
> When I use a particular non-Windows device to format the card, there's
> often one (or several) specifically named folder(s) on the freshly
> formatted card. For example, if it's a camera (or a phone with camera)
> doing the formatting, there's often a DCIM folder created, along with a
> Camera (or similarly named) subfolder, purpose-built for the use of the
> device doing the formatting.
> 
> It might be (but no guarantees here) that, without those idiosyncratic
> folders, the device won't recognize the card. HTH. Cheers, -- tlvp

These "idiosyncratic" folders are part of the DCF standard which
describes the structure of file systems for cameras, so any device which
has to deal with memory cards from a camera (e.g. photo printers) know
what to expect on it:

<https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_system>

Usually the structure gets created automatically on formatted but empty
cards.

-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37280

Bill wrote:

> In message <VA.00000c22.00519969@me.invalid>, Daniel James 
> <daniel@me.invalid> writes
>> What is more of a worry is the failure mode when the flash does begin 
>> to fail. Ideally the whole device would just become read-only so that 
>> no data would be lost, but one hears of more severe failures with no 
>> data recoverable, which is a worry. I suspect that this is more likely 
>> with SD cards than with SATA etc SSDs, as the controllers are 
>> necessarily less sophisticated.
> As the OP and as this has gone slightly OT, what is the reason why it is 
> often recommended that SD cards in dashcams be regularly formatted in 
> the dashcam?
> 
> In my case, the new 64GB and 128GB SD cards showed in W7 as being 
> formatted  FAT32.They weren't initially recognised in the cam.
> 
> Formatted in the cam and they were recognised and work well.
> When W7 displays their properties, they are both still shown as 
> formatted FAT32.

Maybe the camera changed the partitioning as well.

But I would have expected exFAT since this is the official file system
in the standard for SDXC (even though SDXC cards can be formatted to
other file systems as well).


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37030

nospam wrote:


> In article <efd310f355.DaveMeUK@my.inbox.com>, Dave Higton
> <dave@davehigton.me.uk> wrote:
> 
>>>> If you really want to get as much "internal" memory as possible and do
>>>> backups regularly, then use the SD card as "internal". But since SD
>>>> cards are prone to errors as more you write on them
>>>
>>> complete nonsense.
>>
>> Nonsense on your part.  It does happen, with some SD cards that
>> buyers believe to be perfectly respectable.  I've had it happen
>> with three Kingston cards.
> 
> there is no reason whatsoever why writing to an sd card or any other
> type of flash memory will cause it to slow down over time. that's
> absolute nonsense.

I did not say - "slow down" - I said "prone to errors".

Before a flash memory block can be written it has to be erased first if
it was already in use. Even if only one single byte has to be changed,
then the whole block has to be read first, then the single byte is
changed and then the block is written again - either a new block which
was never be used before or to an unused block (unused in the meaning
that the data on it is no longer needed) which has to be erased first.

The more data you write on a flash based memory device the less free
blocks are left which can be written without erasing them first. But
erasing a block also means additional wear for the flash memory.

Of course the OS will try to minimize write operations as much as
possible by using caches and collecting all changes over a certain
period of time before writing back the changes - but generally the more
you write the more you wear the memory. SD cards are also not very
expensive any longer and they are not intended to be long term storage
devices - so the manufacturer will try to save costs wherever possible.

> one possibility is that volumes formatted as fat tend to be slower with
> a large number of files. perhaps that's what you're seeing. a simple
> reformat fixes that.

Fragmented file systems will get slower on hard discs due to the slow
seek times of the magnetic heads. This is not the case for flash based
storage devices - fragmentation is in fact no problem at all there. The
whole file allocation table will be cached in memory anyway to speed up
the access time.


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37022

In article <1e2e766b-6ecd-8e16-e465-705be4107df5@arnowelzel.de>, Arno
Welzel <usenet@arnowelzel.de> wrote:

> >> If you really want to get as much "internal" memory as possible and do
> >> backups regularly, then use the SD card as "internal". But since SD
> >> cards are prone to errors as more you write on them
> > 
> > complete nonsense.
> 
> No, practical experience (about 80 devices and around 400 sd cards with
> a failure rate of about 5% over 4 years).

then you bought shitty cards.

> >> and they are also
> >> sometimes way slower than the flash memory in the phone itself,
> > 
> > that part is likely true, but the difference probably won't make uch of
> > a difference because mobile devices are typically cpu-bound, not
> > i/o-bound.
> 
> Depends on what kind of application you use.

that's why i said typically and not guaranteed in every case.

> >> this
> >> *may* not be a good idea if you don't have high quality SD cards.
> > 
> > why would anyone buy a shit quality card? the good ones aren't that
> > much more.
> 
> Well - if people would only buy quality stuff, then the cheapo stuff
> wouldn't exist at all since nobody would buy it. But in fact people
> sometimes buy stuff just to save 10% or less.

and they have only themselves to blame.

[toc] | [prev] | [next] | [standalone]

#37029

nospam wrote:

> In article <1e2e766b-6ecd-8e16-e465-705be4107df5@arnowelzel.de>, Arno
> Welzel <usenet@arnowelzel.de> wrote:
> 
>>>> If you really want to get as much "internal" memory as possible and do
>>>> backups regularly, then use the SD card as "internal". But since SD
>>>> cards are prone to errors as more you write on them
>>>
>>> complete nonsense.
>>
>> No, practical experience (about 80 devices and around 400 sd cards with
>> a failure rate of about 5% over 4 years).
> 
> then you bought shitty cards.

Then Sandisk, Toshiba, Kingston etc. are all "shitty".



-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37096

In message <6a0577e0-182f-d303-691c-6ecd7facbbbf@arnowelzel.de>
          Arno Welzel <usenet@arnowelzel.de> wrote:

>nospam wrote:
>
>> In article <1e2e766b-6ecd-8e16-e465-705be4107df5@arnowelzel.de>, Arno
>> Welzel <usenet@arnowelzel.de> wrote:
>> 
>>>>> If you really want to get as much "internal" memory as possible and do
>>>>> backups regularly, then use the SD card as "internal". But since SD
>>>>> cards are prone to errors as more you write on them
>>>>
>>>> complete nonsense.
>>>
>>> No, practical experience (about 80 devices and around 400 sd cards with
>>> a failure rate of about 5% over 4 years).
>> 
>> then you bought shitty cards.
>
>Then Sandisk, Toshiba, Kingston etc. are all "shitty".

According to nospam's bizarre logic, my experience also is that
Kingston cards are "shitty".

Dave

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.mobile.android

csiph-web