Jim Lesurf writes:
Richard Kettlewell wrote:
Jim Lesurf writes:
So what would you suggest in terms of a filing system address like
/run/user.... ? If your answer is "none of them" then I will stick
with what suits me and leave others to do what they prefer. But if
there is a common and recommended 'location', I can use it.

As I said, use $TMPDIR if set, otherwise use /tmp. It's a standard
location for temporary files and is often a tmpfs.

I'll need to unpack that because of my ignorance.

My mint laptop (for example) has /tmp. But 'df' doesn't list it, so does
that mean its on the main SDD simply as a directory. i.e. *not* a tempfs
(or ramfs) on ram?

In general, yes.

If you want your own /tmp to be a tmpfs, do that.

That I don't currently know how to do. Nor do I know if it might give
a problem for something else. There are already two directories inside
/tmp.

I don’t know Mint. But:

In Debian systems, historically, you could edit /etc/default/tmpfs and
set RAMTMP=yes. /tmp would be a tmpfs after the next reboot. In newer
Debian systems, with systemd, you’d enable tmp.mount.

On practically any Linux system adding a line to /etc/fstab should work.
Again, it would take effect after the next reboot.

Migrating to any different filesystem on /tmp without a reboot risks
breaking the running things that rely on it, hence the general theme of
rebooting to turn it on.

If you want a guarantee that your program will always have a tmpfs
available at some predictable location: sorry, you can't have one.

I take it that by "can't" what you really mean is that "the user would have
to be willing to create one. Which in turn means I'd have to explain /
request that *if* I wanted them to use a tempfs"?

Yes. There’s no filename you can bake into your program that will
always be a tmpfs.

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

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.

--
Tciao for Now!

John

In ,
Jim Lesurf wrote:

A question occurs to me prompted by the way the Flack Health Check program
works. (And which I may also use for CD Health Check.)

In operations it relies on writing a tempory file, reading back its
contents, deleting the file, then repeating the process. The 'cycle' takes
somewhat less than a second per tempfile.

Is the file really necessary? If you want to avoid touching the disk
[1], the best way is to avoid using a file. Does the program that reads
the file need to seek around in it, or can it just read it serially? If
the reader and writer are separate programs use a pipe. If they're the
same program just use a RAM buffer. If the files are small enough to
consider using a RAM disk there's no reason not to just load the whole
thing into RAM anyway.

[1] AIUI that's the accepted spelling even in British English for
computer storage devices.

In article , Tony Houghton
wrote:
In , Jim Lesurf
wrote:

A question occurs to me prompted by the way the Flack Health Check
program works. (And which I may also use for CD Health Check.)

In operations it relies on writing a tempory file, reading back its
contents, deleting the file, then repeating the process. The 'cycle'
takes somewhat less than a second per tempfile.

Is the file really necessary? If you want to avoid touching the disk
[1], the best way is to avoid using a file. Does the program that reads
the file need to seek around in it, or can it just read it serially?

I'm calling flac to read successive 5-sec chunks from a flac file. Each
time the flac utility will presumably have to seek.

I am aware there are many ways to do what I've done. However I've done it
so far in the way I found easiest and most familiar.

If the reader and writer are separate programs use a pipe.

I may have done if I'd known how to. But in practice I wanted to get a
program that produced the required coconut without too much delay. So far
as I'm concerned, the purpose of the programs I write are to produce a
result. It's nice to learn more about programming, but that's not my
main aim.

I still don't know in sufficient detail how to use a pipe for this. But I
do now know how to set up a 'ramdisc' for myself. Which strikes me as a
perfectly reasonably method - and one I'm familiar with from RO.

Note that - as I've already explained - any user of the program will be
able to choose whatever storage device and directory they wish for the
tempfiles. And that anyone who wants can modify the program as they prefer.
Source code provided. So if someone wished - say - to make a 'load the
entire LPCM in one go' version, or one that pipes, that's fine with me.


If they're the same program just use a RAM buffer. If the files are
small enough to consider using a RAM disk there's no reason not to just
load the whole thing into RAM anyway.

Afraid I don't know the distinction here between a ram buffer and a ram
disc. And the files vary in (unpacked to LPCM) size. But sizes of 1GB or
more aren't unusual for the files I work on.

There is, perhaps, another point you will appreciate. I wrote this program
initially for RISC OS. So I'm essentially 'porting this to Linux' to give
the opportunity of any interested Linux user to perform the same analysis
on their flac files. Given this and my background I'm avoiding making
needless changes. TBH I'm hoping others will be interested and do a
'better' program for the task - and port to other platforms. My interest
is in the audio analysis. I'm not really much of a programmer. Given
that the Flac program works I'd feel it more productive to do the Audio
CD version once I'm settled.

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

In article , Jim Lesurf
wrote:
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

I'm now trying to determine what I'd add to fstab to get a ramdisc. I've
looked on the web and found various *different* listed fstab lines for
this, so I'm unclear what the line should say.

e.g.

If I first do a

sudo mkdir -p /mnt/ramdisc

Do I add to fstab

tmpfs /mnt/ramdisc tempfs size=XXX 0 0

or

tmpfs /mnt/ramdisc rw 0 0

or

ramdisc /mnt/ramdisc tmpfs mode=1777,size=XXX

or

tmpfs /mnt/ramdisc tmpfs size=XXX,mode=0777 0 0

I've see all these suggested on webpages. Some look like synonyms with
different settings, but others don't.

So what's the recipy?

What I'd like is a ramdisc at /mnt/ramdisc which is of modest size and I
can use for temporary 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

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

What I'd like is a ramdisc at /mnt/ramdisc which is of modest size and I
can use for temporary files.

NB tmpfs is _not_ a ramdisc; it is a filesystem that uses virtual
memory. The different from a traditional RAM disk is that there is no
underlying block device and its contents may be swapped out.

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

In ,
Jim Lesurf wrote:

In article , Tony Houghton
wrote:
In , Jim Lesurf
wrote:

A question occurs to me prompted by the way the Flack Health Check
program works. (And which I may also use for CD Health Check.)

In operations it relies on writing a tempory file, reading back its
contents, deleting the file, then repeating the process. The 'cycle'
takes somewhat less than a second per tempfile.

Is the file really necessary? If you want to avoid touching the disk
[1], the best way is to avoid using a file. Does the program that reads
the file need to seek around in it, or can it just read it serially?

I'm calling flac to read successive 5-sec chunks from a flac file. Each
time the flac utility will presumably have to seek.

Let's make sure I understand what's going on here. You want your program
to analyse a flac file and to do this you're using the flac utility to
decode that file into raw data your program can understand?

I am aware there are many ways to do what I've done. However I've done it
so far in the way I found easiest and most familiar.

And because there wasn't really another way available in RISC OS.

If the reader and writer are separate programs use a pipe.

I may have done if I'd known how to. But in practice I wanted to get a
program that produced the required coconut without too much delay. So far
as I'm concerned, the purpose of the programs I write are to produce a
result. It's nice to learn more about programming, but that's not my
main aim.

I still don't know in sufficient detail how to use a pipe for this. But I
do now know how to set up a 'ramdisc' for myself. Which strikes me as a
perfectly reasonably method - and one I'm familiar with from RO.

You've gone to some trouble to learn how to make a RAM disc, you could
have spent that time learning about pipes. There are several drawbacks
to the RAM disc, eg requires root access to set up, no guaranteed safe
place to mount it, not portable to other types of Unix (eg Apple's OS
X), whereas pipes are the natural way to transfer data between programs
in Unix. It is more complicated than just calling system(), but it's so
fundamental there's almost guaranteed to be a decent tutorial in any
book about Unix programming.

If my assumption above is correct, you just need to do this, in place of
the system() call:

1. Create a pipe with the pipe() function.
2. Call fork(), and in the parent continue as before, except instead of
opening a file you can use fdopen() to read from the output of your pipe.
3. In the child replace stdout with the input to your pipe. I can't
remember exactly how to do that, but I think it's a simple function call
which will be explained in a tutorial.
4. In the child call one of the exec() family of functions to launch
flac, using its --stdout option. man system says execl() is its nearest
epquivalent, but it's worth looking at the others to see if one suits
your use case better. This basically replaces the child fork of your
program with flac, with stdout still hooked up to your pipe.

I'm not sure whether you were splitting the file into 5 second chunks to
avoid filling up a RAM disc, or because your aim is to analyse just 5
seconds at a time, but in the former case there's no need to do that
with pipes. You can just run one instance of flac on the whole file and
let the system handle the buffering.

In article
wwvsiammhjn.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
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.

cf below.

What I'd like is a ramdisc at /mnt/ramdisc which is of modest size and
I can use for temporary files.

NB tmpfs is _not_ a ramdisc; it is a filesystem that uses virtual
memory. The different from a traditional RAM disk is that there is no
underlying block device and its contents may be swapped out.

Yes, I'm aware it may get swapped onto other hardware at times. However
that's not likely to happen much with my systems as when I monitor that it
seems to almost never occur. And even if it does on rare occasion, that's
fair enough. I'm happy to regard any swapping as something I don't have to
notice for my simple programs.

I also realise there is a different Linux system with a name that could be
confused, and behaves differently. But I'm just doing this for my purposes
on my machines, aware of that.

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:
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?

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

In article , Tony Houghton
wrote:
In , Jim Lesurf
wrote:


I'm calling flac to read successive 5-sec chunks from a flac file.
Each time the flac utility will presumably have to seek.

Let's make sure I understand what's going on here. You want your program
to analyse a flac file and to do this you're using the flac utility to
decode that file into raw data your program can understand?

Yes. I call flac to have it read a portion of a flac file and generate an
output file that contains the 'decoded' LPCM values. That's launched by my
main program using a system(flac ...) call. The program then opens and
freads the file to examine and analyse the content. This process is then
repeated chunk-by-chunk until the entire payload of the flac file is done.



I am aware there are many ways to do what I've done. However I've done
it so far in the way I found easiest and most familiar.

And because there wasn't really another way available in RISC OS.

So far I understand, that's the case. However its the only way I've found
practical on RO which avoids me having to produce a flac-standard decoder
that reads directly.


You've gone to some trouble to learn how to make a RAM disc, you could
have spent that time learning about pipes.

I was actually looking into both. But found producing a 'ram disc'
relatively easy using the commands I outlined. Since that also fits nicely
with the RO original sources, I've used it successfully.

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