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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#36955

In message <251220161118286891%nospam@nospam.invalid>
          nospam <nospam@nospam.invalid> wrote:

>In article <0d78f7f355.DaveMeUK@my.inbox.com>, Dave Higton
><dave@davehigton.me.uk> wrote:
>
>> >> Absolutely not - I was addressing the cards at sector level.
>> >
>> >that's not a normal use case.
>> >
>> >when using the card as intended, there is no slowdown. i have over ten
>> >year old sd cards and they work just as well now as they did when they
>> >were new.
>> 
>> Of course it's not a normal use case.  
>
>then it can be ignored.

You're denying reality again.

>> It gives incontrovertible
>> evidence that writing the sectors slowed down, in the case of the
>> three Kingston cards I had, after a period of use.  And it was
>> most, but not all, of the sectors that slowed down - some, at
>> lower addresses, remained fast.
>
>there's this thing called wear leveling.

Yes.  It happens transparently, so that an addressed sector is
replaced without the driving firmware or software knowing about
it.

>some sectors will ultimately slow down so much to not even be used
>anymore.

If you read what I said above, /most/ of the sectors of my Kingston
cards slowed down.  Under those conditions it's impossible for any
filing system not to slow down.

>> If writing the sectors slows down, it is inevitable that writing
>> within a filing system ("using the card as intended") must slow
>> down.
>
>except it doesn't. millions of people don't notice any slowdown at all.

Agreed.  It's also true that some people /do/ notice a slowdown.

Dave

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

#37023

In article <f956805f-b339-fe10-b20a-faed1ff0ff49@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.
> >>
> >> 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".

both are wrong.

> 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.

which is managed by wear leveling.

> 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.

the number of writes before there's a problem is huge.

you'd have to hammer the card with writes every day for years before it
even starts to become a problem.

> > 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.

well designed file systems don't. fat is not well designed and will
slow down with a lot of files.

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

#37028

nospam wrote:

> In article <f956805f-b339-fe10-b20a-faed1ff0ff49@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.
>>>>
>>>> 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".
> 
> both are wrong.
> 
>> 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.
> 
> which is managed by wear leveling.

Correct. But even wear leveling just tries to *level* the number of
writes. It does not change the total number of possible writes in any way.

> the number of writes before there's a problem is huge.

Yes - around 500 to 1000 times of the capacity of the SD card. But even
for much more expensive SSDs the TBW is often lower than this.

> you'd have to hammer the card with writes every day for years before it
> even starts to become a problem.

BTDT - some SD cards even failed after just a couple of months of
regular use.

> well designed file systems don't. fat is not well designed and will
> slow down with a lot of files.

There is no logical reason why this should happen with flash memory.


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

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

#37032

In article <a9d5f932-7b61-0ec9-6954-ac9f7f27c7bb@arnowelzel.de>, Arno
Welzel <usenet@arnowelzel.de> wrote:

> 
> > you'd have to hammer the card with writes every day for years before it
> > even starts to become a problem.
> 
> BTDT - some SD cards even failed after just a couple of months of
> regular use.

that's a defective card. 

nothing is perfect. 

return it under warranty for a refund or replacement. 

> > well designed file systems don't. fat is not well designed and will
> > slow down with a lot of files.
> 
> There is no logical reason why this should happen with flash memory.

it has nothing to do with flash memory. it's a problem with fat.

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

#37059

nospam wrote:

> In article <a9d5f932-7b61-0ec9-6954-ac9f7f27c7bb@arnowelzel.de>, Arno
> Welzel <usenet@arnowelzel.de> wrote:
> 
>>
>>> you'd have to hammer the card with writes every day for years before it
>>> even starts to become a problem.
>>
>> BTDT - some SD cards even failed after just a couple of months of
>> regular use.
> 
> that's a defective card. 
> 
> nothing is perfect. 
> 
> return it under warranty for a refund or replacement. 

Yep - but this brings me back to me original statement, that SD cards
are prone to errors ;-).

A defect is still a defect even it is covered by a warranty.

>>> well designed file systems don't. fat is not well designed and will
>>> slow down with a lot of files.
>>
>> There is no logical reason why this should happen with flash memory.
> 
> it has nothing to do with flash memory. it's a problem with fat.

The only reason for file systems to slow down are increased access
times. There is no other reason. And since access times on flash memory
is not depending on where a logical block is stored it does not matter
which file system you use to *read* data. Only for *writing* data on
flash memory the file system is important to get more or less speed.


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

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

#37073

In article <8e35dade-d5cf-7fd0-a32f-7404b1783b75@arnowelzel.de>, Arno
Welzel <usenet@arnowelzel.de> wrote:


> >>> you'd have to hammer the card with writes every day for years before it
> >>> even starts to become a problem.
> >>
> >> BTDT - some SD cards even failed after just a couple of months of
> >> regular use.
> > 
> > that's a defective card. 
> > 
> > nothing is perfect. 
> > 
> > return it under warranty for a refund or replacement. 
> 
> Yep - but this brings me back to me original statement, that SD cards
> are prone to errors ;-).
> 
> A defect is still a defect even it is covered by a warranty.

nothing is perfect in this world.

> >>> well designed file systems don't. fat is not well designed and will
> >>> slow down with a lot of files.
> >>
> >> There is no logical reason why this should happen with flash memory.
> > 
> > it has nothing to do with flash memory. it's a problem with fat.
> 
> The only reason for file systems to slow down are increased access
> times. There is no other reason. 

yes there is. the biggest reason is an inefficient catalog structure.

> And since access times on flash memory
> is not depending on where a logical block is stored it does not matter
> which file system you use to *read* data. Only for *writing* data on
> flash memory the file system is important to get more or less speed.

nope. read speed is also very important.

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

#37277

nospam wrote:

> In article <8e35dade-d5cf-7fd0-a32f-7404b1783b75@arnowelzel.de>, Arno
> Welzel <usenet@arnowelzel.de> wrote:
[...]
>> And since access times on flash memory
>> is not depending on where a logical block is stored it does not matter
>> which file system you use to *read* data. Only for *writing* data on
>> flash memory the file system is important to get more or less speed.
> 
> nope. read speed is also very important.

I did not say that read speed is not important - I said that the read
speed on a flash memory is not influenced by the position of the blocks
to be read.


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

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

#37308

In article <7a3ee1d6-a9d2-c0a2-92d4-9afb44bf9dc2@arnowelzel.de>, Arno
Welzel <usenet@arnowelzel.de> wrote:

> >> And since access times on flash memory
> >> is not depending on where a logical block is stored it does not matter
> >> which file system you use to *read* data. Only for *writing* data on
> >> flash memory the file system is important to get more or less speed.
> > 
> > nope. read speed is also very important.
> 
> I did not say that read speed is not important - I said that the read
> speed on a flash memory is not influenced by the position of the blocks
> to be read.

the position isn't the issue. the problem is determining which blocks
are the ones to read, which is where the file system comes in.

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

#37667

nospam wrote:

> In article <7a3ee1d6-a9d2-c0a2-92d4-9afb44bf9dc2@arnowelzel.de>, Arno
> Welzel <usenet@arnowelzel.de> wrote:
> 
>>>> And since access times on flash memory
>>>> is not depending on where a logical block is stored it does not matter
>>>> which file system you use to *read* data. Only for *writing* data on
>>>> flash memory the file system is important to get more or less speed.
>>>
>>> nope. read speed is also very important.
>>
>> I did not say that read speed is not important - I said that the read
>> speed on a flash memory is not influenced by the position of the blocks
>> to be read.
> 
> the position isn't the issue. the problem is determining which blocks
> are the ones to read, which is where the file system comes in.

And this does not really change things. The difference is only noticable
when using a mechanical drive which has to move parts to get to the
blocks. But on a flash memory device it doesn't matter. Even a cheap
smartphone has enough RAM to cache the whole FAT of a microSD card
formatted with FAT or exFAT.


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

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

#37670

In article <c1f35eb3-528b-c6b0-d069-ccae73ac6a60@arnowelzel.de>, Arno
Welzel <usenet@arnowelzel.de> wrote:

> >>>> And since access times on flash memory
> >>>> is not depending on where a logical block is stored it does not matter
> >>>> which file system you use to *read* data. Only for *writing* data on
> >>>> flash memory the file system is important to get more or less speed.
> >>>
> >>> nope. read speed is also very important.
> >>
> >> I did not say that read speed is not important - I said that the read
> >> speed on a flash memory is not influenced by the position of the blocks
> >> to be read.
> > 
> > the position isn't the issue. the problem is determining which blocks
> > are the ones to read, which is where the file system comes in.
> 
> And this does not really change things. The difference is only noticable
> when using a mechanical drive which has to move parts to get to the
> blocks. But on a flash memory device it doesn't matter. Even a cheap
> smartphone has enough RAM to cache the whole FAT of a microSD card
> formatted with FAT or exFAT.

the difference is noticeable on both flash and mechanical storage. 

<https://technet.microsoft.com/en-us/library/cc938440.aspx>
  In mathematical terms, the average time to find a file on a FAT
  folder is a function of N/2, where N is the number of files. On an
  NTFS folder, the average time is a function of Log N .

<http://forensicswiki.org/wiki/FAT#FAT_Disadvantages>
  € FAT slows down as the number of files on the disk increases

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

#37710

nospam wrote:

[Huge number of files on a filesystem]
> the difference is noticeable on both flash and mechanical storage. 
> 
> <https://technet.microsoft.com/en-us/library/cc938440.aspx>
>   In mathematical terms, the average time to find a file on a FAT
>   folder is a function of N/2, where N is the number of files. On an
>   NTFS folder, the average time is a function of Log N .

If N/2 is just a few milliseconds the difference does not matter.

> <http://forensicswiki.org/wiki/FAT#FAT_Disadvantages>
>   € FAT slows down as the number of files on the disk increases

Yes - on mechanical hard discs.


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

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

#37768

In article <e5e344b6-2ce5-e53e-26ab-5e79abc1a3cf@arnowelzel.de>, Arno
Welzel <usenet@arnowelzel.de> wrote:

> [Huge number of files on a filesystem]
> > the difference is noticeable on both flash and mechanical storage. 
> > 
> > <https://technet.microsoft.com/en-us/library/cc938440.aspx>
> >   In mathematical terms, the average time to find a file on a FAT
> >   folder is a function of N/2, where N is the number of files. On an
> >   NTFS folder, the average time is a function of Log N .
> 
> If N/2 is just a few milliseconds the difference does not matter.

whether it matters is not the issue. it's a mathematically provable
*fact* that fat is slower as the number of files increase.

> > <http://forensicswiki.org/wiki/FAT#FAT_Disadvantages>
> >   ¤ FAT slows down as the number of files on the disk increases
> 
> Yes - on mechanical hard discs.

on all media.

it's well known that a camera's frame rate can slow down as the card
fills up with images.

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

#37773

nospam wrote:

> it's well known that a camera's frame rate can slow down as the card
> fills up with images.

Yes - because of *writing* gets slower. But I talked about *READING*.


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

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

#37058

In article <a9d5f932-7b61-0ec9-6954-ac9f7f27c7bb@arnowelzel.de>, Arno 
Welzel wrote:
>>> 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.
>> 
>> which is managed by wear leveling.
> 
> Correct. But even wear leveling just tries to *level* the number
> of writes. It does not change the total number of possible writes
> in any way.

The wear levelling process includes a mapping between logical "sectors" 
and physical blocks of flash storage. If an application repeatedly 
updates a particular section of a file on a card that section will be 
remapped each time it is written so that different blocks of flash are 
used.

That doesn't change the total number of times that the card can be 
written, but it does change the number of times that any one logical 
sector can be written (which is rather the point).

>> the number of writes before there's a problem is huge.
> 
> Yes - around 500 to 1000 times of the capacity of the SD card. But
> even for much more expensive SSDs the TBW is often lower than this.

Flash memory used to be more durable, but slower and more expensive. 
Time was, you could get flash memory that was good for several tens of 
thousands of writes per block.

As wear-levelling algorithms have improved the manufacturers have 
decided that it's OK to use faster and cheaper flash with lower total 
write counts. Some flash drives use memory that can only be rewritten a 
few thousand times per block, but still have an expected lifetime of 
over five years with fairly heavy use. That's quite impressive.

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.

>> well designed file systems don't. fat is not well designed and will
>> slow down with a lot of files.
> 
> There is no logical reason why this should happen with flash memory.

As a flash card gets full the write process will become slower as more 
data typically needs to be moved around by the wear-levelling algorithms 
to make room. That's not particularly dependent on the filesystem in 
use, but will be a factor on any device.

SSDs that support the low-level TRIM command are less susceptible to 
this, because TRIM enables the controller to recover empty flash blocks 
ahead of time. I'm not sure how common TRIM support is on SD cards, but 
the FAT filesystem doesn't typically support TRIM (it depends on the 
filesystem driver of the OS in use) and this could explain an apparently 
greater slow-down with FAT than with other filesystems.

-- 
Cheers,
 Daniel.
 

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

#37060

Daniel James wrote:

> In article <a9d5f932-7b61-0ec9-6954-ac9f7f27c7bb@arnowelzel.de>, Arno 
> Welzel wrote:
[...]
>>> well designed file systems don't. fat is not well designed and will
>>> slow down with a lot of files.
>>
>> There is no logical reason why this should happen with flash memory.
> 
> As a flash card gets full the write process will become slower as more 
> data typically needs to be moved around by the wear-levelling algorithms 
> to make room. That's not particularly dependent on the filesystem in 
> use, but will be a factor on any device.

I talk about READING data and "nospams" claim that FAT based systems get
slower with in increasing number of files.

> SSDs that support the low-level TRIM command are less susceptible to 
[...]

Did you even read the thread so far?



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

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

#37071

In article <bad4a6af-a0df-3671-b8e8-589eb15e0b4d@arnowelzel.de>, Arno 
Welzel wrote:
>> As a flash card gets full the write process will become slower
>> as more data typically needs to be moved around by the
>> wear-levelling algorithms to make room. That's not particularly
>> dependent on the filesystem in use, but will be a factor on any
>> device.
> 
> I talk about READING data and "nospams" claim that FAT based systems
> get slower with in increasing number of files.

Yes, ... and I'm trying to analyse how/why that might seem to be the 
case.

As I said: a card may get slower as it gets full, but that's NOT 
something that only happens with FAT.

>> SSDs that support the low-level TRIM command are less susceptible to 
> [...]
> 
> Did you even read the thread so far?

The point is that where TRIM is supported the slow-down when a card gets 
full will be less, because of the information provided by TRIM. If the 
card supports TRIM but the FAT filesystem driver doesn't, then the 
benefit of TRIM won't be seen if the card is formatted with FAT. In that 
case (but AFAICS *only* in that case) "nospam" may be correct.

However, I doubt the flash controllers in most micro-SD cards (unlike 
big SSDs with e.g. SATA interfaces) typically support TRIM.

-- 
Cheers,
 Daniel.
 

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

#37072

In article <VA.00000c24.0503f376@me.invalid>, Daniel James
<daniel@me.invalid> wrote:

> >> As a flash card gets full the write process will become slower
> >> as more data typically needs to be moved around by the
> >> wear-levelling algorithms to make room. That's not particularly
> >> dependent on the filesystem in use, but will be a factor on any
> >> device.
> > 
> > I talk about READING data and "nospams" claim that FAT based systems
> > get slower with in increasing number of files.
> 
> Yes, ... and I'm trying to analyse how/why that might seem to be the 
> case.
> 
> As I said: a card may get slower as it gets full, but that's NOT 
> something that only happens with FAT.

true, but fat is the most common format for memory cards (other than
the ones too large for fat).

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

#37279

Daniel James wrote:

> In article <bad4a6af-a0df-3671-b8e8-589eb15e0b4d@arnowelzel.de>, Arno 
> Welzel wrote:
>>> As a flash card gets full the write process will become slower
>>> as more data typically needs to be moved around by the
>>> wear-levelling algorithms to make room. That's not particularly
>>> dependent on the filesystem in use, but will be a factor on any
>>> device.
>>
>> I talk about READING data and "nospams" claim that FAT based systems
>> get slower with in increasing number of files.
> 
> Yes, ... and I'm trying to analyse how/why that might seem to be the 
> case.
> 
> As I said: a card may get slower as it gets full, but that's NOT 
> something that only happens with FAT.

Yes - this applies to *writing* data, not reading.

There is no reason why a FAT file systems on a flash memory should get
slower for *reading* data when there are more files stored.

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.


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

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

#37303

In article <26aa4a1e-1283-465b-010d-f0d53655763e@arnowelzel.de>, Arno 
Welzel wrote:
>> As I said: a card may get slower as it gets full, but that's NOT 
>> something that only happens with FAT.
> 
> Yes - this applies to *writing* data, not reading.

Absolutely!

> There is no reason why a FAT file systems on a flash memory should get
> slower for *reading* data when there are more files stored.

No, there isn't. That's right. *I* never said there was.

> 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.

Also true.

> Exactly this is, what TRIM does:
> erasing unused blocks in the background, so they are ready when you 
need
> them.

Not exactly, no. TRIM is a command issued by the filesystem driver when 
a file is erased or truncated to tell the flash controller that the 
logical blocks formerly occupied by that file are no longer needed.

The process of erasing unused blocks in the background goes on 
regardless of the use of TRIM, it's just that when TRIM is in use the 
controller knows more about the blocks that are available to be erased 
and reused and so can do the job more effectively.

-- 
Cheers,
 Daniel.
 

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

#37309

In article <26aa4a1e-1283-465b-010d-f0d53655763e@arnowelzel.de>, Arno
Welzel <usenet@arnowelzel.de> wrote:

> >> I talk about READING data and "nospams" claim that FAT based systems
> >> get slower with in increasing number of files.
> > 
> > Yes, ... and I'm trying to analyse how/why that might seem to be the 
> > case.
> > 
> > As I said: a card may get slower as it gets full, but that's NOT 
> > something that only happens with FAT.
> 
> Yes - this applies to *writing* data, not reading.

both.

> There is no reason why a FAT file systems on a flash memory should get
> slower for *reading* data when there are more files stored.

there is, which is why that's what happens.

> 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.

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

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

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

csiph-web