Re: TSC timekeeping and cpu states

[Kevin Oberman]

On Mon, Aug 14, 2017 at 8:38 AM, Ian Smith  wrote:

> On Mon, 14 Aug 2017 17:16:22 +1000, Aristedes Maniatis wrote:
>
>  > On 14/8/17 3:08PM, Kevin Oberman wrote:
>  > > Again, the documentation lags reality. The default was changed for
>  > > 11.0. It is still conservative. In ALMOST all cases, Cmax will yield
>  > > the bast results. However, on large systems with many cores, Cmax
>  > > will trigger very poor results, so the default is C2, just to be
>  > > safe.
>
> Given it's a server, anything beyond C2 is likely not worth trying.
> OTOH, C2 is perhaps not worth avoiding; it's probably low latency and
> should result in lower power consumption, so heat, and unlikely to hurt.
>
> Or at least, I suspect that's the case .. cc'ing Alexander, as the wiki
> article you referenced was his doing, so he's among those best placed.
>
>  > > As far as possible TSC impact, I think older processors had TSC
>  > > issues when not all cores ran with the same clock speed. That said,
>  > > I am not remotely expert on such issues, so don't take this too
>  > > seriously.
>
> I wasn't aware that FreeBSD could yet do different freqs on different
> cores?  But I'm less expert than Kevin, and certainly behind the times.
>
>  > Thanks Kevin
>  >
>  > What does 'large' and 'many cores' mean here? Is 24 cores large or
>  > small? For a server do we ever want the CPU to enter states other
>  > than C1?
>
> If C2 works well on your box, I don't see why you wouldn't want to use
> it .. but others might.  I have no personal experience beyond 2 cores,
> but I'm perennially curious about such issues, as Kevin knows :)
>
> Are you using powerd?  And what says, for example:
>
>  sysctl -a | egrep 'cx|available|_freq|freq_|choice' | grep -v net\.
>
> which should include your timecounter and eventtimer setup too.
>
> cheers, Ian
>

I guess I need to clarify. No, FreeBSD does not have the ability to tun
different cores at different frequencies. I seem to recall that TCC on some
processors could adjust the frequency of a core exceeding a defined
temperature, skipping N of every 8 clock cycles to slow the processor and
reduce the temperature. This is what TCC was designed for. It is entirely
possible that I am not correctly remembering the details of the issue, but
it could only be resolved by switching from TCC to another clocking system.

If memory serves, and it may not, there was an issue a few years ago (jhb@
worked the issue) where TSC was varying with frequency and that caused
clock drift. I believe all "modern" processors do not have this issue and
it seems unlikely that any system running 24 cores is old enough that this
might be an issue.

Sorry for any confusion I may have caused.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: TSC timekeeping and cpu states

[Alexander Motin]

On 14.08.2017 18:38, Ian Smith wrote:
> On Mon, 14 Aug 2017 17:16:22 +1000, Aristedes Maniatis wrote:
>  > On 14/8/17 3:08PM, Kevin Oberman wrote:
>  > > Again, the documentation lags reality. The default was changed for 
>  > > 11.0. It is still conservative. In ALMOST all cases, Cmax will yield 
>  > > the bast results. However, on large systems with many cores, Cmax 
>  > > will trigger very poor results, so the default is C2, just to be 
>  > > safe.
> 
> Given it's a server, anything beyond C2 is likely not worth trying. 
> OTOH, C2 is perhaps not worth avoiding; it's probably low latency and 
> should result in lower power consumption, so heat, and unlikely to hurt.
> 
> Or at least, I suspect that's the case .. cc'ing Alexander, as the wiki 
> article you referenced was his doing, so he's among those best placed.

C-states controlled here are ACPI C-states, which have limited relation
to real CPU C-states.  There are systems where they map exactly, but
there are also systems where ACPI C1/C2/C3 states map to CPU C1/C3/C6,
so it is difficult to make general recommendations.  Approximately the
map can be guessed looking on latency value (last of three) reported in
sysctl dev.cpu.0.cx_supported:  1 is usually CPU C1, 2+ is likely CPU
C2, 100+ can be C3, 500+ can be C6, but all that is very approximately
and I guess depends on BIOS writer mood.

What's about recommendations from me, I'd say that CPU C2 state should
not hurt in most cases, unless something is broken, but benefit is
rather small (often just covered by C1E enabled in BIOS);  CPU C3 state
gives significant power saving, but can either hurt performance due to
higher enter/exit latency or slightly improve it due to TurboBoost
activation (require CPU frequency to be set to max value); CPU C6 is
probably useful only for laptops, since it saves not so much power
power, while exit latency can be in milliseconds range.

>  > > As far as possible TSC impact, I think older processors had TSC
>  > > issues when not all cores ran with the same clock speed. That said,
>  > > I am not remotely expert on such issues, so don't take this too 
>  > > seriously.
> 
> I wasn't aware that FreeBSD could yet do different freqs on different 
> cores?  But I'm less expert than Kevin, and certainly behind the times.

On old CPUs TSC frequency was related to CPU frequency and so could
fluctuate with frequency change.  On modern CPUs it is always constant,
equal to base CPU frequency.  What's about different frequency for
different cores, IIRC ACPI allows that, but up to recent time neither
FreeBSD nor hardware could do that.  I have feeling I heard that some
very new CPUs may allow that, but to be efficient it would require very
tight interoperation between power manager and CPU scheduler, otherwise
performance may suffer.

-- 
Alexander Motin
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: TSC timekeeping and cpu states

[Ian Smith]

On Mon, 14 Aug 2017 17:16:22 +1000, Aristedes Maniatis wrote:

 > On 14/8/17 3:08PM, Kevin Oberman wrote:
 > > Again, the documentation lags reality. The default was changed for 
 > > 11.0. It is still conservative. In ALMOST all cases, Cmax will yield 
 > > the bast results. However, on large systems with many cores, Cmax 
 > > will trigger very poor results, so the default is C2, just to be 
 > > safe.

Given it's a server, anything beyond C2 is likely not worth trying. 
OTOH, C2 is perhaps not worth avoiding; it's probably low latency and 
should result in lower power consumption, so heat, and unlikely to hurt.

Or at least, I suspect that's the case .. cc'ing Alexander, as the wiki 
article you referenced was his doing, so he's among those best placed.

 > > As far as possible TSC impact, I think older processors had TSC
 > > issues when not all cores ran with the same clock speed. That said,
 > > I am not remotely expert on such issues, so don't take this too 
 > > seriously.

I wasn't aware that FreeBSD could yet do different freqs on different 
cores?  But I'm less expert than Kevin, and certainly behind the times.

 > Thanks Kevin
 > 
 > What does 'large' and 'many cores' mean here? Is 24 cores large or 
 > small? For a server do we ever want the CPU to enter states other 
 > than C1?

If C2 works well on your box, I don't see why you wouldn't want to use 
it .. but others might.  I have no personal experience beyond 2 cores, 
but I'm perennially curious about such issues, as Kevin knows :)

Are you using powerd?  And what says, for example:

 sysctl -a | egrep 'cx|available|_freq|freq_|choice' | grep -v net\.

which should include your timecounter and eventtimer setup too.

cheers, Ian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Error in /usr/src/release/release.sh

[Glen Barber]

On Mon, Aug 14, 2017 at 09:12:04AM -0600, Ian Lepore wrote:
> On Mon, 2017-08-14 at 14:34 +, Glen Barber wrote:
> > On Mon, Aug 14, 2017 at 08:26:59AM -0600, Ian Lepore wrote:
> > > 
> > > On Mon, 2017-08-14 at 13:23 +, Glen Barber wrote:
> > > > 
> > > > On Mon, Aug 14, 2017 at 01:18:14PM +, Glen Barber wrote:
> > > > > 
> > > > > 
> > > > > On Sat, Aug 12, 2017 at 05:12:02PM +, Bryce Edwards wrote:
> > > > > > 
> > > > > > 
> > > > > > When trying to build a set of RELENG/11.1 release files, I'm
> > > > > > getting the
> > > > > > following error (tail end of output) in the release.sh run:
> > > > > > ---
> > > > > > ---
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Kernel build for ALLWINNER completed on Fri Aug 11
> > > > > > > > > 22:24:02
> > > > > > > > > UTC 2017
> > > > > > ---
> > > > > > ---
> > > > > > make -C /usr/src/release  obj
> > > > > > make -C /usr/src/release  ftp
> > > > > > `ftp' is up to date.
> > > > > This makes me think a populated release directory within
> > > > > ${.OBJDIR}
> > > > > (i.e., /usr/obj/usr/src/release) already existed (perhaps from
> > > > > a previous 11.1-RELEASE build?).
> > > > > 
> > > > > Could you retry after moving the release directory in the obj
> > > > > tree
> > > > > out
> > > > > of the way?  Everything from your release.conf looks sane
> > > > > otherwise.
> > > > > 
> > > > Actually, at second look, it seems you are missing
> > > > EMBEDDEDBUILD=1 in
> > > > your release.conf.  arm/armv6 targets should not create the 'ftp'
> > > > directory - the SoC u-boot loader address is baked in during the
> > > > world
> > > > build, making it infeasible to create the ftp bits.
> > > > 
> > > > Glen
> > > > 
> > > Except the u-boot loader address hasn't actually been used for
> > > about 2
> > > years in arm builds.  I don't know anything about this ftp stuff or
> > > what this thread is about, but I do know that UBLDR_LOADADDR is no
> > > longer used in arm builds, and thus should not be preventing
> > > anything
> > > else from working.
> > > 
> > Hmm, I thought UBLDR_LOADADDR was still used.  Good to know.
> > 
> > Regarding ftp, the "big-iron" builds create a ftp directory as part
> > of
> > the release target, which contains the distribution sets used by
> > various
> > things such as bootonly.iso and poudriere.
> > 
> > That said, should we now expect that a userland build between all
> > arm/armv6 SoCs to be identical (modulo any baked-in timestamps)?
> > 
> > Glen
> > 
> 
> Hrm.  Well apparently, UBLDR_LOADADDR is no longer needed, but it is
> still used when building ubldr (not ubldr.bin), and some old uboot
> scripts still refer to ubldr.  So we've got to clean those up before we
> can finish eliminating UBLDR_LOADADDR.
> 

Ok, thanks for the information.  I'll leave UBLDR_LOADADDR in the build
tools for now.

Glen



signature.asc
Description: PGP signature

Re: Error in /usr/src/release/release.sh

[Ian Lepore]

On Mon, 2017-08-14 at 14:34 +, Glen Barber wrote:
> On Mon, Aug 14, 2017 at 08:26:59AM -0600, Ian Lepore wrote:
> > 
> > On Mon, 2017-08-14 at 13:23 +, Glen Barber wrote:
> > > 
> > > On Mon, Aug 14, 2017 at 01:18:14PM +, Glen Barber wrote:
> > > > 
> > > > 
> > > > On Sat, Aug 12, 2017 at 05:12:02PM +, Bryce Edwards wrote:
> > > > > 
> > > > > 
> > > > > When trying to build a set of RELENG/11.1 release files, I'm
> > > > > getting the
> > > > > following error (tail end of output) in the release.sh run:
> > > > > ---
> > > > > ---
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Kernel build for ALLWINNER completed on Fri Aug 11
> > > > > > > > 22:24:02
> > > > > > > > UTC 2017
> > > > > ---
> > > > > ---
> > > > > make -C /usr/src/release  obj
> > > > > make -C /usr/src/release  ftp
> > > > > `ftp' is up to date.
> > > > This makes me think a populated release directory within
> > > > ${.OBJDIR}
> > > > (i.e., /usr/obj/usr/src/release) already existed (perhaps from
> > > > a previous 11.1-RELEASE build?).
> > > > 
> > > > Could you retry after moving the release directory in the obj
> > > > tree
> > > > out
> > > > of the way?  Everything from your release.conf looks sane
> > > > otherwise.
> > > > 
> > > Actually, at second look, it seems you are missing
> > > EMBEDDEDBUILD=1 in
> > > your release.conf.  arm/armv6 targets should not create the 'ftp'
> > > directory - the SoC u-boot loader address is baked in during the
> > > world
> > > build, making it infeasible to create the ftp bits.
> > > 
> > > Glen
> > > 
> > Except the u-boot loader address hasn't actually been used for
> > about 2
> > years in arm builds.  I don't know anything about this ftp stuff or
> > what this thread is about, but I do know that UBLDR_LOADADDR is no
> > longer used in arm builds, and thus should not be preventing
> > anything
> > else from working.
> > 
> Hmm, I thought UBLDR_LOADADDR was still used.  Good to know.
> 
> Regarding ftp, the "big-iron" builds create a ftp directory as part
> of
> the release target, which contains the distribution sets used by
> various
> things such as bootonly.iso and poudriere.
> 
> That said, should we now expect that a userland build between all
> arm/armv6 SoCs to be identical (modulo any baked-in timestamps)?
> 
> Glen
> 

Hrm.  Well apparently, UBLDR_LOADADDR is no longer needed, but it is
still used when building ubldr (not ubldr.bin), and some old uboot
scripts still refer to ubldr.  So we've got to clean those up before we
can finish eliminating UBLDR_LOADADDR.

-- Ian
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Error in /usr/src/release/release.sh

[Glen Barber]

On Mon, Aug 14, 2017 at 08:26:59AM -0600, Ian Lepore wrote:
> On Mon, 2017-08-14 at 13:23 +, Glen Barber wrote:
> > On Mon, Aug 14, 2017 at 01:18:14PM +, Glen Barber wrote:
> > > 
> > > On Sat, Aug 12, 2017 at 05:12:02PM +, Bryce Edwards wrote:
> > > > 
> > > > When trying to build a set of RELENG/11.1 release files, I'm
> > > > getting the
> > > > following error (tail end of output) in the release.sh run:
> > > > --
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > Kernel build for ALLWINNER completed on Fri Aug 11 22:24:02
> > > > > > > UTC 2017
> > > > --
> > > > make -C /usr/src/release  obj
> > > > make -C /usr/src/release  ftp
> > > > `ftp' is up to date.
> > > This makes me think a populated release directory within ${.OBJDIR}
> > > (i.e., /usr/obj/usr/src/release) already existed (perhaps from
> > > a previous 11.1-RELEASE build?).
> > > 
> > > Could you retry after moving the release directory in the obj tree
> > > out
> > > of the way?  Everything from your release.conf looks sane
> > > otherwise.
> > > 
> > Actually, at second look, it seems you are missing EMBEDDEDBUILD=1 in
> > your release.conf.  arm/armv6 targets should not create the 'ftp'
> > directory - the SoC u-boot loader address is baked in during the
> > world
> > build, making it infeasible to create the ftp bits.
> > 
> > Glen
> > 
> 
> Except the u-boot loader address hasn't actually been used for about 2
> years in arm builds.  I don't know anything about this ftp stuff or
> what this thread is about, but I do know that UBLDR_LOADADDR is no
> longer used in arm builds, and thus should not be preventing anything
> else from working.
> 

Hmm, I thought UBLDR_LOADADDR was still used.  Good to know.

Regarding ftp, the "big-iron" builds create a ftp directory as part of
the release target, which contains the distribution sets used by various
things such as bootonly.iso and poudriere.

That said, should we now expect that a userland build between all
arm/armv6 SoCs to be identical (modulo any baked-in timestamps)?

Glen



signature.asc
Description: PGP signature

Re: Error in /usr/src/release/release.sh

[Ian Lepore]

On Mon, 2017-08-14 at 13:23 +, Glen Barber wrote:
> On Mon, Aug 14, 2017 at 01:18:14PM +, Glen Barber wrote:
> > 
> > On Sat, Aug 12, 2017 at 05:12:02PM +, Bryce Edwards wrote:
> > > 
> > > When trying to build a set of RELENG/11.1 release files, I'm
> > > getting the
> > > following error (tail end of output) in the release.sh run:
> > > --
> > > > 
> > > > > 
> > > > > > 
> > > > > > Kernel build for ALLWINNER completed on Fri Aug 11 22:24:02
> > > > > > UTC 2017
> > > --
> > > make -C /usr/src/release  obj
> > > make -C /usr/src/release  ftp
> > > `ftp' is up to date.
> > This makes me think a populated release directory within ${.OBJDIR}
> > (i.e., /usr/obj/usr/src/release) already existed (perhaps from
> > a previous 11.1-RELEASE build?).
> > 
> > Could you retry after moving the release directory in the obj tree
> > out
> > of the way?  Everything from your release.conf looks sane
> > otherwise.
> > 
> Actually, at second look, it seems you are missing EMBEDDEDBUILD=1 in
> your release.conf.  arm/armv6 targets should not create the 'ftp'
> directory - the SoC u-boot loader address is baked in during the
> world
> build, making it infeasible to create the ftp bits.
> 
> Glen
> 

Except the u-boot loader address hasn't actually been used for about 2
years in arm builds.  I don't know anything about this ftp stuff or
what this thread is about, but I do know that UBLDR_LOADADDR is no
longer used in arm builds, and thus should not be preventing anything
else from working.

-- Ian

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Error in /usr/src/release/release.sh

[Glen Barber]

On Mon, Aug 14, 2017 at 01:18:14PM +, Glen Barber wrote:
> On Sat, Aug 12, 2017 at 05:12:02PM +, Bryce Edwards wrote:
> > When trying to build a set of RELENG/11.1 release files, I'm getting the
> > following error (tail end of output) in the release.sh run:
> > --
> > >>> Kernel build for ALLWINNER completed on Fri Aug 11 22:24:02 UTC 2017
> > --
> > make -C /usr/src/release  obj
> > make -C /usr/src/release  ftp
> > `ftp' is up to date.
> 
> This makes me think a populated release directory within ${.OBJDIR}
> (i.e., /usr/obj/usr/src/release) already existed (perhaps from
> a previous 11.1-RELEASE build?).
> 
> Could you retry after moving the release directory in the obj tree out
> of the way?  Everything from your release.conf looks sane otherwise.
> 

Actually, at second look, it seems you are missing EMBEDDEDBUILD=1 in
your release.conf.  arm/armv6 targets should not create the 'ftp'
directory - the SoC u-boot loader address is baked in during the world
build, making it infeasible to create the ftp bits.

Glen



signature.asc
Description: PGP signature

Re: Error in /usr/src/release/release.sh

[Glen Barber]

On Sat, Aug 12, 2017 at 05:12:02PM +, Bryce Edwards wrote:
> When trying to build a set of RELENG/11.1 release files, I'm getting the
> following error (tail end of output) in the release.sh run:
> --
> >>> Kernel build for ALLWINNER completed on Fri Aug 11 22:24:02 UTC 2017
> --
> make -C /usr/src/release  obj
> make -C /usr/src/release  ftp
> `ftp' is up to date.

This makes me think a populated release directory within ${.OBJDIR}
(i.e., /usr/obj/usr/src/release) already existed (perhaps from
a previous 11.1-RELEASE build?).

Could you retry after moving the release directory in the obj tree out
of the way?  Everything from your release.conf looks sane otherwise.

Glen



signature.asc
Description: PGP signature

Re: nullfs making contents of ZFS datasets invisible even after unmounting

[tsuroerusu]

With a little bit of help, I managed to figure out what the problem
was. It turned out that I had run, head first, into the wall of nullfs
not operating across file systems. Thus inside the jail, the data was
being saved to a regular directory on my "storage/cloud"-dataset
(Mountpoint: /storage/cloud), whereas outside the jail the child file
system "storage/cloud/bc", having been left empty, was mounted over
the folder "bc" on "storage/cloud", where the files actually resided,
thus "hiding" them from view outside the jail. A simple "zfs unmount
storage/cloud/bc" revealed them.

Anybody reading this in the future: If you are using ZFS and want to
put a file system and all of its children into a jail then you cannot
use nullfs. Instead you need to either change the actual mount point
using "zfs set mountpoint=/jails/jail1/storage
storage/path/to/filesystem" or to attach the entire dataset to the
jail, and allow it to be managed from within the jail using "zfs
jail".

2017-08-14 10:34 GMT+02:00  :
> I am running a FreeBSD 11.1 system with ZFS and jails and I mount a
> file system on my storage pool (/storage/cloud) into the jail
> (/jails/cloud/storage) via nullfs, and that works fine for what the
> jail does. However I just noticed that outside the jail, I can only
> see the mount points of the file system children, but not the
> contents.
>
> For example if I do: ls -la /storage/cloud/* (As root) then nothing
> shows up, but they are present inside the jail. Even if I stop the
> jail, they still are not present outside the jail.
>
> I just tried disabling jails in /etc/rc.conf and rebooting the system
> and EVEN THEN the files do not reappear outside the jail in their
> original location, yet zfs list reports the space being used. But if I
> then (without rebooting) enable the jail, the files show up in the
> nullfs-mounted location inside the jail!
>
> As an experiment, I tried creating /mnt/test and /mnt/test2 and
> creates a folder and a few files in test, and then nullfs-mounted it
> onto test2, and I could then see the files in both locations.
>
> Does anybody know what might be causing this? The fact that my data
> stays hidden after a reboot is rather worrisome.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: zfs listing and CPU

[Tenzin Lhakhang]

Interesting, even the illumos man page doesn't have the -c defined.  I
remember reading about it at one point.

I can only get `zfs get -Hrpc all` working, even though -c is not
documented.  So, I retract my statement on the zfs list with cached.

# zfs get -*Hpc* -o property,value name,used,avail zones
namezones
used1219313598464
available   761203195904

# I use the above way to create easily parseable zfs_dataset objects.

As for needing immediate/latest version of zfs list on entity creation --
you ideally want a way to do cache invalidation or use some sort of
message/event driven system between the client that creates the entity and
the server.  You can perform the cache invalidation by monitoring the
'creation' events that come to your API, or by tailing zpool history [pool]
for changes.

- I recently read this article and they show a nice way to decouple the
storage events and the api, architecture is not entirely new but can be
adapted to your case.
- https://medium.freecodecamp.org/million-websockets-and-go-cc58418460bb

Thanks,
Tenzin

On Sun, Aug 13, 2017 at 2:25 PM, Eugene M. Zheganin 
wrote:

> On 13.08.2017 16:13, Tenzin Lhakhang wrote:
>
>> You may want to have an async zfs-get program/script that regularly does
>> a zfs get -Ho and stores then in a local cache (redis or your own program)
>> at a set interval and then the api can hit the cache instead of directly
>> running get or list.
>>
> I cannot because the cache will become stale on first new entity creation,
> which happens all the time.
>
> - Some silly person will try to benchmark your zfs web-API and overload
>> your server with zfs processes.
>> - Example: let me run [ ab -c 10 -n 1 http://yourserver/zfs-api/list
>> ]
>> -- Let me run 10 concurrent connection with a total of 10k requests to
>> your api (it's a simple one liner -- people will be tempted to benchmark
>> like this).
>>
>> Example:
>> https://github.com/tlhakhan/ideal-potato/blob/master/zdux/ro
>> uters/zfs/service.js#L9
>> - This is a JS example, but you can easily script it or another language
>> (golang) for cache separation and another program for the API.
>>
>> Also, zfs does have a -c property to get cached values -- these values
>> are stored in an internal zfs process cache. The -c doesn't help if you
>> have 1000(0)s of filesystems, a single list can still take minutes.
>> Sending the list is also several megabytes.
>>
> Doesn't have on FreeBSD.
>
>
>
> Thanks.
> Eugene.
> ___
> freebsd...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

nullfs making contents of ZFS datasets invisible even after unmounting

[tsuroerusu]

I am running a FreeBSD 11.1 system with ZFS and jails and I mount a
file system on my storage pool (/storage/cloud) into the jail
(/jails/cloud/storage) via nullfs, and that works fine for what the
jail does. However I just noticed that outside the jail, I can only
see the mount points of the file system children, but not the
contents.

For example if I do: ls -la /storage/cloud/* (As root) then nothing
shows up, but they are present inside the jail. Even if I stop the
jail, they still are not present outside the jail.

I just tried disabling jails in /etc/rc.conf and rebooting the system
and EVEN THEN the files do not reappear outside the jail in their
original location, yet zfs list reports the space being used. But if I
then (without rebooting) enable the jail, the files show up in the
nullfs-mounted location inside the jail!

As an experiment, I tried creating /mnt/test and /mnt/test2 and
creates a folder and a few files in test, and then nullfs-mounted it
onto test2, and I could then see the files in both locations.

Does anybody know what might be causing this? The fact that my data
stays hidden after a reboot is rather worrisome.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: TSC timekeeping and cpu states

[Aristedes Maniatis]

On 14/8/17 3:08PM, Kevin Oberman wrote:
> Again, the documentation lags reality. The default was changed for 11.0. It 
> is still conservative. In ALMOST all cases, Cmax will yield the bast results. 
> However, on large systems with many cores, Cmax will trigger very poor 
> results, so the default is C2, just to be safe.
> 
> As far as possible TSC impact, I think older processors had TSC issues when 
> not all cores ran with the same clock speed. That said, I am not remotely 
> expert on such issues, so don't take this too seriously.

Thanks Kevin

What does 'large' and 'many cores' mean here? Is 24 cores large or small? For a 
server do we ever want the CPU to enter states other than C1?


Ari


-- 
-->
Aristedes Maniatis
CEO, ish
https://www.ish.com.au
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"