In article
wwvmw0um9m6.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:
Jim Lesurf writes:
Richard Kettlewell wrote:
Jim Lesurf writes:
I've see all these suggested on webpages. Some look like synonyms
with different settings, but others don't.

So what's the recipy?

That depends what you want. Only you can decide that. 'man mount'
describes the meaning of the options. On one system I have:

tmpfs /tmp tmpfs defaults,size=8G,nr_inodes=256k,nosuid 0 0

Sorry, I'd assumed that from the context of the previous discussions
it would have been reasonably clear what I'd like. I said in an
earlier posting:

I've found that I can do something like

sudo mkdir -p /mnt/tmp

followed by

sudo -t tmpfs -o size=20m tmpfs /mnt/tmp

to create a temporary 20meg 'ram disc' mounted at /mnt/tmp

and that does what I want. But the second command needs repeating
after each bootup.

So my aim is to have this setup automatically via fstab, but I'd
prefer a name /mnt/ramdisc and a size of, say, 128m. I'd like that
name because it reminds me of what I can easily use for my RO programs
where the data is stored in ram.

So do that. What's stopping you?

Because its still not clear to me what specific values I should put on the
fstab line. I found examples which looked different in ways that weren't
clear to me. Hence asking here for help on the issue.

Having used

sudo mkdir -p /mnt/ramdisc

what should I add to fstab to get the same as from my giving the command

sudo -t tmpfs -o size=128m tmpfs /mnt/ramdisc

after every bootup? And essentially gived a way to save/read/etc my
temporary files (usually) in ram for the duration of a session/

Jim





--

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Jim Lesurf writes:
Richard Kettlewell wrote:
So do that. What's stopping you?

Because its still not clear to me what specific values I should put on the
fstab line. I found examples which looked different in ways that weren't
clear to me. Hence asking here for help on the issue.

Having used

sudo mkdir -p /mnt/ramdisc

what should I add to fstab to get the same as from my giving the command

sudo -t tmpfs -o size=128m tmpfs /mnt/ramdisc

after every bootup? And essentially gived a way to save/read/etc my
temporary files (usually) in ram for the duration of a session/

Did you try reading the man page I referred to?

--
http://www.greenend.org.uk/rjk/

In article
wwvy4kdnbu9.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:
Jim Lesurf writes:
Richard Kettlewell wrote:
So do that. What's stopping you?

Because its still not clear to me what specific values I should put on
the fstab line. I found examples which looked different in ways that
weren't clear to me. Hence asking here for help on the issue.

Having used

sudo mkdir -p /mnt/ramdisc

what should I add to fstab to get the same as from my giving the
command

sudo -t tmpfs -o size=128m tmpfs /mnt/ramdisc

after every bootup? And essentially gived a way to save/read/etc my
temporary files (usually) in ram for the duration of a session/

Did you try reading the man page I referred to?

Yes, along with various books and webpages on the topic. But none have
clarified this for me. And as I pointed out, examples I found showed
different and apparently conflicting texts for such an fstab line. Leaving
me little wiser as to the specific line I should use.

Alas, for those who *don't* already know all the answers 'man pages' may
be little more than a list of options or settings which don't tell the
reader *how* to use them appropriately for the situation you want. Fine
as reminders to those who already understand. But less use if you
don't.

That isn't a Linux problem. It crops up for all OS's and all kinds of
software where the author of the software wrote the 'documentation'. And
when doing so took for granted things the reader may not know.

Of all the 'example' versions I found the one that looked most likely to be
what I'd want from the above commands would be

tmpfs /mnt/ramdisc tmpfs nodev,nosuid,size=128m 0 0

as an added line to fstab having first used mkdir -p /mnt/ramdisc

But I've seen so many other examples said to be ways to do this for what
I'm after that the 'man page' doesn't resolve for me.

Hence why I keep explaining what I want to do, and asking for help.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Jim Lesurf writes:
Richard Kettlewell wrote:
Jim Lesurf writes:
Richard Kettlewell wrote:
So do that. What's stopping you?

Because its still not clear to me what specific values I should put on
the fstab line. I found examples which looked different in ways that
weren't clear to me. Hence asking here for help on the issue.

Having used

sudo mkdir -p /mnt/ramdisc

what should I add to fstab to get the same as from my giving the
command

sudo -t tmpfs -o size=128m tmpfs /mnt/ramdisc

after every bootup? And essentially gived a way to save/read/etc my
temporary files (usually) in ram for the duration of a session/

Did you try reading the man page I referred to?

Yes, along with various books and webpages on the topic. But none have
clarified this for me. And as I pointed out, examples I found showed
different and apparently conflicting texts for such an fstab line. Leaving
me little wiser as to the specific line I should use.

Alas, for those who *don't* already know all the answers 'man pages' may
be little more than a list of options or settings which don't tell the
reader *how* to use them appropriately for the situation you want. Fine
as reminders to those who already understand. But less use if you
don't.

That isn't a Linux problem. It crops up for all OS's and all kinds of
software where the author of the software wrote the 'documentation'. And
when doing so took for granted things the reader may not know.

Of all the 'example' versions I found the one that looked most likely to be
what I'd want from the above commands would be

tmpfs /mnt/ramdisc tmpfs nodev,nosuid,size=128m 0 0

as an added line to fstab having first used mkdir -p /mnt/ramdisc

But I've seen so many other examples said to be ways to do this for what
I'm after that the 'man page' doesn't resolve for me.

OK. Some of the possible lines you quoted have a mode= parameter, but
your command doesn’t, and you say don’t know if those lines are suitable
for you. *I don’t know either* because I don’t know what behavior you
actually want. I can’t tell the difference between (1) you do want it,
but don’t know to add it to the mount command and (2) you don’t want it,
but don’t know to remove it from the fstab line.

That’s why I pointed you at the mount man page, because that’s where
that parameter is described. My guess would be that you don’t want it,
but I can’t read your mind.

--
http://www.greenend.org.uk/rjk/

In article
wwv8ucdm0fu.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:
Jim Lesurf writes:
[snip waste of effort]

OK. Some of the possible lines you quoted have a mode= parameter, but
your command doesn't, and you say don't know if those lines are suitable
for you. *I don't know either* because I don't know what behavior you
actually want. I can't tell the difference between (1) you do want it,
but don't know to add it to the mount command and (2) you don't want it,
but don't know to remove it from the fstab line.

I've repeatedly explained the behaviour I want, and my program examples the
kind of use intended. Sorry if that hasn't been clear enough. I'll ask
elsewhere.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

On Sat, 23 May 2015 10:57:37 +0100, Jim Lesurf wrote:

That looks like worth trying. However I'm not clear on details so would
like to check some points:

1) When calling flac using system() can I just replace the flac
command's final switch/setting

I don't use flac but did read its manpage. That says that if you read the
input from stdin, the output gets written to stdout, i.e. in this mode
flac is intended to be used as one element in a pipeline. OTOH, if your
input comes from a file named in the command line, the output will be
written to a named output file.

-o outputfile

If it understood the manpage correctly, if you want to use this, the
input should be read from a named file


with something like

inputfile | RunImage

Again, if I read the manpage correctly. this should be used in a pipeline:

flac inputfile | next_program_in_the_pipeline

OR, presumably.

flac inputfile outfile

would also work.

Will the output be readable as a stream of bytes/chars I can use to fill
a buffer?

....but don't take my word for it: read the manpage and try the various
options for yourself using a small input file and some program like
'hexdump' to examine the output file and see what got written to it.

===== change of topic ======

FILE flacfile = tmpfile();

No.

FILE* flacfile = tmpfile();

is a C statement that creates a variable called flacfile that your
program can use to store sequential data that will be written into
flacfile and read back (one or more times) by your program. flacfile is a
variable created within your program and obeys variable normal scoping
rules. It is never written to the filing system because it has no name
that can ever be seen from outside your program. If you want to save its
content as a file, you'd need to open an output file and copy its
contents into that.

will mean it will read as stdin when I use flacfile as the 'handle'?

No. See above. You can fill it with fwrite(), and access it with rewind()
or fseek() and friends followed with fread(). If the flacfile variable
goes out of scope the data it contains will be discarded and the memory
that held the data will be released. If you call fclose() the data will
be lost.

Can I also use fread() of the correctly sized block rather than read as
a series of bytes/chars/etc?

Yes. Because it has a variable type of FILE* all the usual fread(), fwrite
(), fseek(), rewind() etc operations should work on it but, because it
exists only in the RAM occupied by your program, these should all be fast
operations unless, of course, you put so much data into it that it
overflows physical RAM and parts of it get written to swap space.

Is there an example I can see of this? I'll do a websearch, but as yet
don't know anything about it!

Pass. Try searching for examples.

Thanks again, this is interesting. I've know of the existence and
general pupose of pipes, but no idea how to use them.

This isn't a pipeline, which is a command line construct, e.g.

ls -ll *.c | sort --key=5 -g

is a pipeline that lists the details of all C source files "ls -ll *.c"
and sorts the files by size "sort --key=5 -g". '|' is the pipeline symbol
that says that the output that 'ls' writes to stdout will be fed into the
stdin input of 'sort'


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

In ,
Martin Gregorie wrote:

Again, if I read the manpage correctly. this should be used in a pipeline:

flac inputfile | next_program_in_the_pipeline

OR, presumably.

flac inputfile outfile

would also work.

That's a point. I could have given you much simpler advice, Jim. As
Martin has pointed out, you can pipe programs together with the shell,
so you don't need to launch flac from your C program, either using
system(), or all that stuff about exec() I told you.

You're writing it as a ROX app, I think you said, and I see "RunImage"
in what Martin quoted. I used to use ROX a long time ago. But I think if
you've followed the usual template your app should contain a shell
script called AppRun. Assuming that you run it by dragging a file onto
its icon in ROXFiler I think the filename will be available to AppRun as
$1. So you can change the line that launches your RunImage to something
like:

exec flac ... --stdout $1 | $AppDir/RunImage

where ... represents any other options you need to give to flac.

You need to change the C code too, but you'll be making it simpler, not
more complicated. Instead of repeatedly calling system() then reading a
temporary file from a ramfs in 5 second chunks, just read from stdin and
treat it as one long file. To do that use the global variable stdin in
your calls to fread() etc instead of your own FILE * variable. You could
make the fread() load 5 seconds' worth at a time in a loop if that's
what your code is designed to analyse.

Then you can use the same technique for the CD version without having to
make any changes at all to the C.

In article , Tony Houghton
wrote:
In ,
Martin Gregorie wrote:

Thanks to you both for the postings on pipes, etc. I've 'locked' them both
in Pluto to keep for future reference and I will experiment with the
methods at some point to see how I get on.

At present, though, I've experimented with setting up a tempfs 'ramdisc'
sic at /mnt/ramdisc and adding an fstab line that seems to work nicely.
So for now I'll use that as I find it simpler because of my past
experience.

The updated program I release will behave by default as the present
version, but allow the user to choose a directory they prefer for tempfiles
if they wish. That's a quite seperate issue to using a 'ram' location for
it.

I need to update the RO Flac_HealthCheck as I spotted a minor bug when
working on the Linux version. Once the above is done I'll look again at the
CD program and if a pipe might be easier for me there or not. Although my
first experiments will be to see if I can bypass that entirely by using the
CD libraries, etc, to read 'directly into my main program. So may not need
pipes or temp files at all.

But as before my main interest is in making the ability to carry out the
analysis possible for anyone who wishes. So may decide, again, to release a
version that uses my methods and welcome anyone interested to produce what
they feel is a 'better' version. Plain truth is that I'm not a good
programmer, and it isn't my main interest. I just bang rocks together to
get the fire. If I were a *good* programmer I'd probably built the Flac
decoding into my program in the first place! 8-]

Question: should the same sort of 'piping' be possible for using the RO
flac port?

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

On Sat, 23 May 2015 21:03:19 +0100, John Williamson wrote:

On 23/05/2015 12:55, Jim Lesurf wrote:
In article , Tim Watts
wrote:
I would not worry about SSD wear - I have been using them in laptops
for a while - my current one is over a year old and shows 100% on the
Wear_Leveling_Count (that's good, 0% is "dead").

I'm not particularly worried about SSD wear as I've also (so far) used
some for years. But some of the people who use my program may be using
conventional spinning rust. And there *are* wear mechanisms for SSD
according to reports I've read. Just that in practice I (and many
others) don't seem to have run into problems with it.

From what I've read, early flash memory cells had a limited life,
measured in thousands of writes, with unlimited reads being safe, while
new types have write lives in the millions of cycles due to improvements
in manufacturing techniques as the technology has matured. New ones also
have more redundancy built in, so the controller can transparently
replace failing cells with unused ones until the spares have all been
used.

You basically have that arse about face. The very early flash devices
had erase/write cycles initially measured in tens of thousands, rising to
hundreds of thousands culminating in millions before the controllers
gained wear levelling capabilities that allowed smaller scale nand cells
with reducing erase/write cycle limits that allowed larger nand cell
counts on the die.

The early SSDs with proper wear levelling used slc nand with e/w cycle
ratings of 30000 or so which, due to reducing cell dimensions and mlc tlc
have e/w cycle lifetimes as low as a mere 3000 or even less. The overall
endurance ratings of modern SSDs are the result of much larger
capacities, some over provisioning (7 to 15% afaicr) and yet more
sophisticated wear levelling controller technology.

The real key to being able to get acceptable life out of a modern SSD
lies with the sheer capacity increases which now require a petabyte or
more's worth of write activity to wear out a 512GB SSD that's using nand
with only a nominal 1500 to 3000 e/w cycle rating thanks, essentially due
to the clever way the controller can spread the wear amongst the nand
cells in the whole array.

A quick 'n' dirty calculation reveals that writing as much as 100GB a
day to a 512GB SSD using nand cells rated for 1500 cycles with the
benefit of wear levelling should last for just over 20 years of 7 days a
week usage. You'd have to be writing/erasing a good 400GB a day to reduce
the service life of such an SSD to a mere 5 years.

In practice, the vast majority of home PC users are unlikely to subject
their systems to much more than 1 to 10 GBs per day. Even people like me
recording several gigabyte's worth of freeview media files a day are
unlikely to top 30GB a day with SD content (or 50GB a day with HD
content).

By the time you've worn out a 500GB SSD, the time for an upgrade will be
long overdue and you'll likely be looking at a 5TB unit with nand cells
rated for a mere 300 cycles or less but, due to the higher capacity, will
last at least the next 5 years or so despite a guesstimated quadrupling
in data throughput.

Ultimately, we may see petabyte sized SSDs with nand cell cycle limits
of just ten cycles which will last 5 years simply because it will take 6
months of 24/7 operating time just to completely write a single set of
data to completely exhaust the SSD's capacity!

Indeed, the ultimate may be to do away with the erase cycle altogether
once capacities of data storage devices start being measured in dozens of
petabytes. Clever controller technologies will probably start using
techniques whereby older data can be recycled to simulate the storage of
new data by clever remapping and 'diffing'. Obviously this will require a
relatively small proportion of high cycle endurance nand for the
controller's own use but the vast majority could consist of worm type
memory cells with the much greater density worm chips making up the bulk
of the storage device.

In the end, your only means of EOL 'secure erasure' for those petabyte
sized SSDs may simply be an electric furnace with an SSD sized slot
through to which to feed your redundant storage devices. Mind you, it's
very likely by then that HMG will have made GCHQ provide a free backup
service as part of the covenant of the universal surveillance pact with
the electorate. :-)

--
Johnny B Good

I have now put up a Linux version of CD_HealthCheck. This can be found
alongside Flac_HealthCheck via a link on

http://www.audiomisc.co.uk/software/index.html

As usual, source code is provided. Anyone interested can use/modify/etc
that as they like.

To save myself time and effort, this version piggybacks on cdparanoia. But
it works OK here. If anyone wants to do a better version, please do!

Similarly, I'd welcome someone porting these programs to Windows / Macs so
that others can carry out similar analysis on their CDs / flac files.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html