Thanks for the input on softdep. I read a lot on the pros and cons.
This certainly pushes me in the "con" direction.
I forgot to mention that I am using 6.6 stable, not current, so the
latest updates to softdep shouldn't be an issue.
Dave Raymond
On 1/8/20, Jan Stary wrote:
> On Jan 08 08:31:2
On 2020-01-08, Nick Holland wrote:
> Weird stuff happens when Softdeps are working as designed.
To put it simply: Meta-data writes are delayed.
--
Christian "naddy" Weisgerber na...@mips.inka.de
On Jan 08 08:31:26, n...@holland-consulting.net wrote:
> Another place where softdeps will sometimes bite you is when you
> unpack tar balls that overwrite existing files -- simple thought
> process says, "as long as you have enough space to cover the growth,
> fine". Softdeps might surprise you.
On 2020-01-07 14:06, Karel Gardas wrote:
>
>
> On 1/7/20 7:38 PM, Jordan Geoghegan wrote:
>> > Using softdep on /tmp is a silly idea. >
> Why? To naive eyes it may look like a natural solution: e.g. before temp
> file is even created (on drive), it may be deleted which means there is
> no meta
On Tue, Jan 07, 2020 at 10:16:22AM -0700, Raymond, David wrote:
> On an AMD-64 workstation /tmp fills up to 105% according to df,
> apparently as a result of UNIX pipes in a shell script passing a whole
> lot of moderately big files. Examination of /tmp with du and ls -gal
> on /tmp shows no big fi
On 2020-01-07 11:06, Karel Gardas wrote:
On 1/7/20 7:38 PM, Jordan Geoghegan wrote:
> Using softdep on /tmp is a silly idea. >
Why? To naive eyes it may look like a natural solution: e.g. before
temp file is even created (on drive), it may be deleted which means
there is no meta-data cha
On 1/7/20 7:38 PM, Jordan Geoghegan wrote:
> Using softdep on /tmp is a silly idea. >
Why? To naive eyes it may look like a natural solution: e.g. before temp
file is even created (on drive), it may be deleted which means there is
no meta-data change hence speedup of operation on /tmp. In c
On 2020-01-07 09:16, Raymond, David wrote:
On an AMD-64 workstation /tmp fills up to 105% according to df,
apparently as a result of UNIX pipes in a shell script passing a whole
lot of moderately big files. Examination of /tmp with du and ls -gal
on /tmp shows no big files and trying to delete
On Tue, Jan 7, 2020 at 12:18 PM Raymond, David
wrote:
> On an AMD-64 workstation /tmp fills up to 105% according to df,
> apparently as a result of UNIX pipes in a shell script passing a whole
> lot of moderately big files. Examination of /tmp with du and ls -gal
> on /tmp shows no big files and
On an AMD-64 workstation /tmp fills up to 105% according to df,
apparently as a result of UNIX pipes in a shell script passing a whole
lot of moderately big files. Examination of /tmp with du and ls -gal
on /tmp shows no big files and trying to delete everything that is
there has no effect. Reboot
10 matches
Mail list logo
