On Mon, Jun 25, 2018 at 11:40 AM, tech-lists wrote:
> On 25/06/2018 16:37, Warner Losh wrote:
>
>> While the compat stuff generally works, there are edge cases where it
>> will fail when you have a mixed environment. You're best bet is to
>> reinstall all ports. If you do just a few, you'll hit t
On 25/06/2018 16:37, Warner Losh wrote:
While the compat stuff generally works, there are edge cases where it
will fail when you have a mixed environment. You're best bet is to
reinstall all ports. If you do just a few, you'll hit the edge cases.
Hi,
What do you mean by "mixed environment"? f
On Mon, Jun 25, 2018 at 6:40 AM, tech-lists wrote:
> Hello,
>
> When upgrading an old-ish 12-current (r317212), as per:
>
> 20170523:
>> The "ino64" 64-bit inode project has been committed, which extends
>> a number of types to 64 bits. In
Hello,
When upgrading an old-ish 12-current (r317212), as per:
20170523:
The "ino64" 64-bit inode project has been committed, which extends
a number of types to 64 bits. In order to upgrade, carefully follow
the full procedure documented below under the h
I'm sure stas can figure it out!
-a
On 25 June 2017 at 22:44, Thomas Mueller wrote:
> from Adrian Chadd:
>
>> valgrind broke as part of the ino64 work :(
>
> Valgrind was not on my mind! Your post sent me to
>
> ls -d /usr/ports/*/val*
>
> to find va
from Adrian Chadd:
> valgrind broke as part of the ino64 work :(
Valgrind was not on my mind! Your post sent me to
ls -d /usr/ports/*/val*
to find valgrind, and then read the pkg-descr.
One less tool for getting debugging information when something crashes?
Hi,
valgrind broke as part of the ino64 work :(
-a
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> Maybe not, but I think so. synth(8) requires the ada compiler which means
> lang/gcc6-aux or lang/gcc5-aux and those DID require work to install on
> ino64. I believe that this is now resolved, but I would seriously consider
> simply installing synth from the package. It has n
On Fri, Jun 23, 2017 at 8:19 PM, Thomas Mueller wrote:
> On Fri, Jun 23, 2017 at 4:12 PM, Thomas Mueller
> wrote:
>
> > > I remember some ports on FreeBSD-current were rendered nonbuildable by
> the
> > > introduction of 64-bit inodes (ino64).
>
> > &g
On Fri, Jun 23, 2017 at 4:12 PM, Thomas Mueller wrote:
> > I remember some ports on FreeBSD-current were rendered nonbuildable by the
> > introduction of 64-bit inodes (ino64).
> > What is the progress on resolving those snags?
> > I haven't heard anything re
On Fri, Jun 23, 2017 at 4:12 PM, Thomas Mueller wrote:
> I remember some ports on FreeBSD-current were rendered nonbuildable by the
> introduction of 64-bit inodes (ino64).
>
> What is the progress on resolving those snags?
>
> I haven't heard anything recently and was una
I remember some ports on FreeBSD-current were rendered nonbuildable by the
introduction of 64-bit inodes (ino64).
What is the progress on resolving those snags?
I haven't heard anything recently and was unable to find anything on
wiki.freebsd.org.
So how do I know the current status?
ns with
>>> inodes, are fine with either width.
>>>
>>> That is, I believe that all instances which I looked at during the
>>> ino64 preparation are fine.
>>
>> Thanks for letting me know --and good to know.
>>
>> I've added a note to the
changed to use) uint32_t for inode numbers
> > in the disk-layout definitions. Other places, which calculate inode
> > numbers from inode block numbers, or do some other calculations with
> > inodes, are fine with either width.
> >
> > That is, I believe that all instances wh
from inode block numbers, or do some other calculations with
> inodes, are fine with either width.
>
> That is, I believe that all instances which I looked at during the
> ino64 preparation are fine.
Thanks for letting me know --and good to know.
I've added a note to the bugzilla
ng on-disk layout.
UFS correctly uses (and was changed to use) uint32_t for inode numbers
in the disk-layout definitions. Other places, which calculate inode
numbers from inode block numbers, or do some other calculations with
inodes, are fine with either width.
That is, I believe that all instances which I looked at during the
ino64 preparation are fine.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Top post of context note:
I should have noted up front that:
/usr/src/sys/boot/powerpc/boot1.chrp/boot1.c
does:
#include "ufsread.c"
and that is the context of the __udivdi3
use that is rejected at link time when
clang is used to buildworld for powerpc
or pwoerpc64.
My original note might rea
buildworld via clang for powerpc64 and powerpc fails for lack of
`__udivdi3' referenced in sys/boot/common/ufsread.c fsread_size
code. But this lead to me looking around and I found a conceptually
separate possible issue. . .
sys/sys/_types.h :
typedef __uint64_t __ino_t;/* inode num
> On Mon, Jun 12, 2017 at 10:14 AM, John Baldwin wrote:
> > On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote:
> >> On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote:
> >> > It seems that {rpc.}lockd no longer runs after the ino64 changes on an
On Mon, Jun 12, 2017 at 10:14 AM, John Baldwin wrote:
> On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote:
>> On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote:
>> > It seems that {rpc.}lockd no longer runs after the ino64 changes on any
>> >
On Sunday, June 11, 2017 11:12:25 AM David Wolfskill wrote:
> On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote:
> > It seems that {rpc.}lockd no longer runs after the ino64 changes on any
> > of my systems after a full rebuild of src and ports. No log entries
> >
On Sun, Jun 04, 2017 at 08:57:44AM -0400, Michael Butler wrote:
> It seems that {rpc.}lockd no longer runs after the ino64 changes on any
> of my systems after a full rebuild of src and ports. No log entries
> offer any insight as to why :-(
>
> imb
I don't tend to u
l Butler
Sent: Sunday, June 4, 2017 8:57:44 AM
To: freebsd-current; Rick Macklem
Subject: post ino64: lockd no runs?
It seems that {rpc.}lockd no longer runs after the ino64 changes on any
of my systems after a full rebuild of src and ports. No log entries
offer any insi
It seems that {rpc.}lockd no longer runs after the ino64 changes on any
of my systems after a full rebuild of src and ports. No log entries
offer any insight as to why :-(
imb
___
freebsd-current@freebsd.org mailing list
https
On Wed, 31 May 2017 23:27:16 +0200
Dimitry Andric wrote:
[snip]
> This also applies to other Mozilla products, such as Thunderbird,
> SeaMonkey, and so on. These should all be rebuilt from scratch under
> ino64.
>
FYI Seamonkey still works after updating kernel and world to ino6
01.06.2017 00:29, Konstantin Belousov пишет:
> On Wed, May 31, 2017 at 11:53:39PM +0300, Boris Samorodov wrote:
>> Hi All,
>>
>> Seems that after ino64 transition some java programs stopped
>> to fully function. I.e. java/intellij (IntellJ IDEA and Co)
>> s
On Wed, 31 May 2017 23:27:16 +0200, Dimitry Andric wrote:
> Hi,
>
> Due to the recent ino64 update in 12.0-CURRENT, there have been some
> reports by Firefox port users about crashes. While I personally have
> not experienced these crashes, as I immediately rebuilt all
Hi,
It may by worth to check other java monsters, but I see no problem with
Eclipse and SQL Developer with ino64.
Thanks!
1 июн. 2017 г. 6:29 ДП пользователь "Konstantin Belousov" <
kostik...@gmail.com> написал:
> On Wed, May 31, 2017 at 11:53:39PM +0300, Boris Samorodo
On Wed, May 31, 2017 at 11:53:39PM +0300, Boris Samorodov wrote:
> Hi All,
>
> Seems that after ino64 transition some java programs stopped
> to fully function. I.e. java/intellij (IntellJ IDEA and Co)
> starts but does not show any files.
>
> I'm not sure if it's
Hi,
Due to the recent ino64 update in 12.0-CURRENT, there have been some
reports by Firefox port users about crashes. While I personally have
not experienced these crashes, as I immediately rebuilt all my ports
from scratch after the ino64 update, I think can explain why the
following
Hi All,
Seems that after ino64 transition some java programs stopped
to fully function. I.e. java/intellij (IntellJ IDEA and Co)
starts but does not show any files.
I'm not sure if it's a java or IntelliJ problem. Any help to
diagnose the culprit is welcome.
Thanks.
--
On 30 May 2017 at 12:49, O. Hartmann wrote:
>
> I got a kind of confused, since libunwind seemingly compiles on one box with
> both ino64
> AND WITH_LLD_IS_LD, while it failed after an update of a bunch of systems
> towards ino64.
So was this just confusion over what was ac
On 05/28/2017 08:54, Pete Wright wrote:
Hi all,
I can't imagine that this is related to INO64, but since upgrading my
world and kernel on drm-next (which merged upstream CURRENT as of May
27 which should include the ino64 work) I am having segfaults running
firefox. Previous to
Am Mon, 29 May 2017 14:45:16 -0400
Ed Maste schrieb:
> On 29 May 2017 at 04:59, O. Hartmann wrote:
> > After updating several boxes running CURRENT after introduction of ino64, I
> > have one box which persitently rejects compiling and installing
> > devel/libunwind, a
On 29 May 2017 at 10:49, Ed Maste wrote:
> The ino64 project was committed to src last week[1][2] with
> UPDATING notes added shortly thereafter [3][4][5].
I've now added an anti-foot-shooting test[6] which invokes the new
rescue binary prior to proceeding with installworld. This s
I would appreciate observations about two difficulties that have
surfaced for me since the mesa-libs and ino64 updates. Likely these are
pilot errors but I've not been able to identify the causes.
Here's the environment ...
FreeBSD silver 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r31823
On 29 May 2017 at 04:59, O. Hartmann wrote:
> After updating several boxes running CURRENT after introduction of ino64, I
> have one box which persitently rejects compiling and installing
> devel/libunwind, as you can finde below.
>
> The box in question is running FreeBSD 1
The ino64 project was committed to src last week[1][2] with
UPDATING notes added shortly thereafter [3][4][5].
As some people have been tripped up by the ino64 change I want to
emphasize again that the upgrade procedure described in UPDATING should
be followed exactly. The reboot after installing
After updating several boxes running CURRENT after introduction of ino64, I
have one box which persitently rejects compiling and installing
devel/libunwind, as you can finde below.
The box in question is running FreeBSD 12.0-CURRENT #22 r319083: Sun May 28
21:18:52 CEST 2017 amd64
-curr...@freebsd.org
[mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Oleg V. Nauman
Sent: Sunday, May 28, 2017 6:45 PM
To: freebsd-current@freebsd.org
Subject: Re: INO64 Effecting Firefox
On Sunday 28 May 2017 18:09:19 O. Hartmann wrote:
> Am Sun, 28 May 2017 08:54:35 -0700
>
&g
On Sunday 28 May 2017 18:09:19 O. Hartmann wrote:
> Am Sun, 28 May 2017 08:54:35 -0700
>
> Pete Wright schrieb:
> > Hi all,
> >
> > I can't imagine that this is related to INO64, but since upgrading my
> > world and kernel on drm-next (which merged upstream
Am Sun, 28 May 2017 08:54:35 -0700
Pete Wright schrieb:
> Hi all,
>
> I can't imagine that this is related to INO64, but since upgrading my
> world and kernel on drm-next (which merged upstream CURRENT as of May 27
> which should include the ino64 work) I am havi
Hi all,
I can't imagine that this is related to INO64, but since upgrading my
world and kernel on drm-next (which merged upstream CURRENT as of May 27
which should include the ino64 work) I am having segfaults running
firefox. Previous to this firefox was very stable for work/personal
On 27 May 2017 at 12:25, Thomas Laus wrote:
> After the
> first boot, I tried to install the pkg system. The first fault said
> that the libarchive.so.6 was missing.
Yes, the most recent package set available is built against a
pre-ino64 world and depends on older versions of librar
stalled in /usr/local/bin had
"REAL" strange permissions and dates. The dates were all December
1969 and before the Unix epoch date of January 1970. Something is
wrong with INO64 on a recent snapshot!
Tom
--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuP
Simon J. Gerraty wrote:
> Peter Jeremy wrote:
> > In my case, I have "WITH_META_MODE=yes" in /etc/src-env.conf and was
> > using "make buildworld" - which failed. The upgrade worked cleanly
> > when I manually deleted all the .meta files. If I get a round tuit,
>
> sys.mk is setup such that m
amd D10800
> >devel/libgtopD10795
> >sysutils/py-psutil D1081
> >lang/rust D10799
> >
> > I intend to commit this tomorrow, after the ino64 get some probation time,
> > long enough to
Am Wed, 24 May 2017 08:40:17 -0600
Alan Somers schrieb:
> On Wed, May 24, 2017 at 4:42 AM, Hartmann, O. wrote:
> > On almost every CURRENT that has been updated according to UPDATING
> > entry 2017-05-23 regarding ino64, the recommended update process ends
> > up in a de
Peter Jeremy wrote:
> In my case, I have "WITH_META_MODE=yes" in /etc/src-env.conf and was
> using "make buildworld" - which failed. The upgrade worked cleanly
> when I manually deleted all the .meta files. If I get a round tuit,
sys.mk is setup such that missing .meta file makes the target
out
On 2017-May-24 20:21:54 +0300, Konstantin Belousov wrote:
>No SIGSEGV etc, so I think that the effects seen are due to build system.
>rm -rf obj/* is the safest trick, I believe.
But the behaviour does indicate that meta mode is not doing the right thing
under all circumstances. It's blatently b
On 2017-May-24 18:01:42 -0700, "Simon J. Gerraty" wrote:
>Peter Jeremy wrote:
>> as follows. My suspicion is that meta mode isn't seeing enough of the
>> differences between the bootstrap and main build steps and so causing make
>> to incorrectly skip steps.
>
>I see a number of places in src/Ma
nd leaves open the
possibility of supporting 255-unicode-character filesystems natively
in FreeBSD down the road.
> Actually allowing longer names seems too complicated to add to the ino64
> change, but changing d_namlen to uint16_t (using d_pad0 space) and
> skipping entries with d_namlen &
Peter Jeremy wrote:
> as follows. My suspicion is that meta mode isn't seeing enough of the
> differences between the bootstrap and main build steps and so causing make
> to incorrectly skip steps.
I see a number of places in src/Makefile* where BUILD_TOOLS_META=.NOMETA
is added to env of things
>lang/rust D10799
>
> I intend to commit this tomorrow, after the ino64 get some probation time,
> long enough to ensure that it does not get immediate revert. You may
> see the discussions and use the patches locally, meantime.
devel/libgtop is also b
On 2017-May-24 08:47:41 -0700, Ngie Cooper wrote:
>There was another report on the list about a stale MAKEOBJDIRPREFIX
> causing someone grief. I think it's safe to say that meta mode and -DNO_CLEAN
> might not work across this transition--in particular meta mode tends to err
> on the side
On Wed, May 24, 2017 at 01:42:39PM -0700, Simon J. Gerraty wrote:
> David Wolfskill wrote:
> > As far as I can tell, the "ld" command was:
>
> Since you have the .meta file, it should tell you exactly what the
> command was and what path was actually exec'd
And now that I'm not running around li
Ngie Cooper wrote:
> There was another report on the list about a stale
> MAKEOBJDIRPREFIX causing someone grief.
Pointer?
What does stale MAKEOBJDIRPREFIX mean?
>I think it's safe to say that
> meta mode and -DNO_CLEAN might not work across this transition--in
> particular meta mode tends
David Wolfskill wrote:
> As far as I can tell, the "ld" command was:
Since you have the .meta file, it should tell you exactly what the
command was and what path was actually exec'd
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org
rtmann, O." schrieb:
>
> > On Wed, 24 May 2017 14:31:08 +0300
> > Konstantin Belousov wrote:
> >=20
> > > On Wed, May 24, 2017 at 12:42:19PM +0200, Hartmann, O. wrote: =20
> > > > On almost every CURRENT that has been updated according to UPDATING
&g
to UPDATING
> > > entry 2017-05-23 regarding ino64, the recommended update process
> > > ends up in a desaster or, if the old environemnt/kernel is intact,
> > > itr doesn't work.
> > >
> > > Procedure:
> > >
> > > make -jX build
pleted successfully and a reboot shows:
>
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354
> r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/GENERIC amd64
>
I performed a local experiment
llvm39 D10796
lang/llvm40 D10797
lang/ghc D10798
multimedia/webcamd D10800
devel/libgtopD10795
sysutils/py-psutil D1081
lang/rustD10799
I intend to commit this tomorrow, after the ino64 ge
>Compiling toml v0.1.30
>Compiling bootstrap v0.0.0
> (file:///wrkdirs/usr/ports/lang/rust/work/rustc-1.
> 17.0-src/src/bootstrap)
> Finished dev [unoptimized] target(s) in 31.38 secs
> Build completed unsuccessfully in 0:00:45
> gmake[1]: *** [Makefile:24: all] Error 245
>
>
> ... and lots more ports skipped because of the above.
HardenedBSD, too, is seeing huge fallout with package building due to
ino64.
Thanks,
--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
I just upgraded by package build box and its poudriere jail to r318776
and ran into some significant package build fallout.
devel/llvm40:build:
/usr/bin/c++ -DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -O2 -pipe
-fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem
/usr
> On May 24, 2017, at 08:15, David Wolfskill wrote:
...
> It completed successfully and a reboot shows:
>
> FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #354
> r318781M/318781:1200031: Wed May 24 07:31:48 PDT 2017
> r...@freebeast.catwhisker.org:/common/S3/obj/usr/
On Wed, May 24, 2017 at 07:20:01AM -0700, David Wolfskill wrote:
> ...
> > > I have updated /usr/src back to 318781, then started a new build.
> > So are you building stock 318781, or did you reverted r318750 ?
>
> Stock 318781 [*]. I revert as a (nearly) last resort. :-)
>
> > > While it has no
On Wed, May 24, 2017 at 4:42 AM, Hartmann, O. wrote:
> On almost every CURRENT that has been updated according to UPDATING
> entry 2017-05-23 regarding ino64, the recommended update process ends
> up in a desaster or, if the old environemnt/kernel is intact, itr
> doesn't wo
On Wed, May 24, 2017 at 05:16:38PM +0300, Konstantin Belousov wrote:
> On Wed, May 24, 2017 at 06:59:05AM -0700, David Wolfskill wrote:
> > On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote:
> > > If build of r318739 succed, can you try, please, to rebuild the current
> > > latest
On Wed, May 24, 2017 at 06:59:05AM -0700, David Wolfskill wrote:
> On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote:
> > If build of r318739 succed, can you try, please, to rebuild the current
> > latest sources, but now with reverted r318750 ?
>
> It did complete successfully.
On Wed, May 24, 2017 at 04:35:58PM +0300, Konstantin Belousov wrote:
> ...
> > (lldb) bt
> > * thread #1, name = 'ld', stop reason = signal SIGSEGV
> > * frame #0: 0x
> > (lldb)
> >
> > which isn't entirely unexpected, I suppose, given the nature of SIGSEGV.
> Useful gdb is in p
On Wed, 24 May 2017 14:31:08 +0300
Konstantin Belousov wrote:
> On Wed, May 24, 2017 at 12:42:19PM +0200, Hartmann, O. wrote:
> > On almost every CURRENT that has been updated according to UPDATING
> > entry 2017-05-23 regarding ino64, the recommended update process
> > end
On Wed, May 24, 2017 at 06:01:43AM -0700, David Wolfskill wrote:
> On Wed, May 24, 2017 at 02:10:08PM +0200, Dimitry Andric wrote:
> > ...
> > > building special pic c library
> > > --- libc.so.7 ---
> > > cc: error: unable to execute command: Segmentation fault (core dumped)
> > > cc: error: linke
24.05.2017 16:00, Glen Barber пишет:
> On Wed, May 24, 2017 at 03:47:47PM +0300, Boris Samorodov wrote:
>> Hi All,
>>
>> Does anyone know the procedure to upgrade for those using base packages?
>
> 'pkg install FreeBSD-kernel-generic' (or whatever your kernel package is
> called), reboot, 'pkg upg
On Wed, May 24, 2017 at 02:10:08PM +0200, Dimitry Andric wrote:
> ...
> > building special pic c library
> > --- libc.so.7 ---
> > cc: error: unable to execute command: Segmentation fault (core dumped)
> > cc: error: linker command failed due to signal (use -v to see invocation)
> > *** [libc.so.7]
On Wed, May 24, 2017 at 03:47:47PM +0300, Boris Samorodov wrote:
> Hi All,
>
> Does anyone know the procedure to upgrade for those using base packages?
>
'pkg install FreeBSD-kernel-generic' (or whatever your kernel package is
called), reboot, 'pkg upgrade'.
Glen
signature.asc
Description: P
Hi All,
Does anyone know the procedure to upgrade for those using base packages?
--
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/
On Wed, May 24, 2017 at 04:59:31AM -0700, David Wolfskill wrote:
> Yesterday's in-place src update (r318606 -> r318739) was a bit more
> "interesting" than usual; as has been noted elsewhere, it really is
> necessary to boot the new kernel before the "make installworld"
> completes successfully. T
On 24 May 2017, at 13:59, David Wolfskill wrote:
>
> Yesterday's in-place src update (r318606 -> r318739) was a bit more
> "interesting" than usual; as has been noted elsewhere, it really is
> necessary to boot the new kernel before the "make installworld"
> completes successfully. That said, it
Yesterday's in-place src update (r318606 -> r318739) was a bit more
"interesting" than usual; as has been noted elsewhere, it really is
necessary to boot the new kernel before the "make installworld"
completes successfully. That said, it ("make installworld") did
complete successfully, and a follo
On Wed, May 24, 2017 at 12:42:19PM +0200, Hartmann, O. wrote:
> On almost every CURRENT that has been updated according to UPDATING
> entry 2017-05-23 regarding ino64, the recommended update process ends
> up in a desaster or, if the old environemnt/kernel is intact, itr
>
On almost every CURRENT that has been updated according to UPDATING
entry 2017-05-23 regarding ino64, the recommended update process ends
up in a desaster or, if the old environemnt/kernel is intact, itr
doesn't work.
Procedure:
make -jX buildworld buildkernel [successful]
make installk
765 bytes long in UTF-8. This was reported in PR 204643. The code
> > > > currently handles this by returning the short (8.3) name, but this name
> > > > may not be present or usable, leaving the file inaccessible.
> > > > Actually allowing longer names see
this by returning the short (8.3) name, but this name
> > > may not be present or usable, leaving the file inaccessible.
>
> > > Actually allowing longer names seems too complicated to add to the ino64
> > > change, but changing d_namlen to uint16_t (using d_pad0 space)
ng the file inaccessible.
> > Actually allowing longer names seems too complicated to add to the ino64
> > change, but changing d_namlen to uint16_t (using d_pad0 space) and
> > skipping entries with d_namlen > 255 in libc may be helpful.
> > Note that applications using
gt; upto 765 bytes long in UTF-8. This was reported in PR 204643. The code
> currently handles this by returning the short (8.3) name, but this name
> may not be present or usable, leaving the file inaccessible.
>
> Actually allowing longer names seems too complicated to add to the ino6
2^32 objects. Many modern file systems internally use 64-bit identifiers
> and FreeBSD needs to follow suit to properly and fully support these
> file systems.
> The 64-bit inode project, also known as ino64, started life many years
> ago as a project by Gleb Kurtsou (gleb@). After th
t
> > values to identify inodes, which limits file systems to somewhat under
> > 2^32 objects. Many modern file systems internally use 64-bit identifiers
> > and FreeBSD needs to follow suit to properly and fully support these
> > file systems.
> >
> > The 64-bit in
2^32 objects. Many modern file systems internally use 64-bit identifiers
> and FreeBSD needs to follow suit to properly and fully support these
> file systems.
>
> The 64-bit inode project, also known as ino64, started life many years
> ago as a project by Gleb Kurtsou (gleb@
needs to follow suit to properly and fully support these
file systems.
The 64-bit inode project, also known as ino64, started life many years
ago as a project by Gleb Kurtsou (gleb@). After that time several
people have had a hand in updating it and addressing regressions, after
mckusick@ picked up
89 matches
Mail list logo
