search for: 64kib

...can be at most: 65536 - 2 * ADV_SIZE - 512. > > > > Certain file systems (such as BTRFS and UFS2) will rely on ldlinux.sys being installed on the 0-64k range, > > thus it can't exceed the limit, otherwise the superblock would be corrupted. Raphael/Paulo: does UFS2 have a hard 64kiB limit? I know it's not installed to the first sector where the first superblock is located. > IMNSHO is including core/ldlinux_limit.pl better > than waiting for a better core/ldlinux_limit.pl This should be rendered obsolete and unnecessary with the recent patch for ldlinux.sys on btr...

Hi, I created a RAID1 array of two physical HDD's with chunk size of 64KiB under Debian "wheezy" using mdadm. As a next step, I would like to create an ext3(or ext4) file-system to this RAID1 array using mke2fs utility. According to RAID-related tutorials, I should create the file-system like this: # mkfs.ext3 -v -L myarray -m 0.5 -b 4096 -E stride=16,stripe-wi...

Hi Genec, On Sun, May 25, 2014 11:27 am, Gene Cumm wrote: > Raphael/Paulo: does UFS2 have a hard 64kiB limit? I know it's not > installed to the first sector where the first superblock is located. I have no much experience with UFS2 filesystem. I've just took a quick look at its internals and I can see that UFS2 places its superblock at either 64KiB or 256KiB (depending on the media bei...

...only make sense for RAI-5/6 arrays. > For RAID-1 it doesn't really matter. > > Cheers, Andreas > >> On Mar 6, 2014, at 13:46, Martin T <m4rtntns@gmail.com> wrote: >> >> Hi, >> >> I created a RAID1 array of two physical HDD's with chunk size of 64KiB under Debian "wheezy" using mdadm. As a next step, I would like to create an ext3(or ext4) file-system to this RAID1 array using mke2fs utility. According to RAID-related tutorials, I should create the file-system like this: >> >> # mkfs.ext3 -v -L myarray -m 0.5 -b 4096 -E st...

Note that stride and stripe width only make sense for RAI-5/6 arrays. For RAID-1 it doesn't really matter. Cheers, Andreas > On Mar 6, 2014, at 13:46, Martin T <m4rtntns@gmail.com> wrote: > > Hi, > > I created a RAID1 array of two physical HDD's with chunk size of 64KiB under Debian "wheezy" using mdadm. As a next step, I would like to create an ext3(or ext4) file-system to this RAID1 array using mke2fs utility. According to RAID-related tutorials, I should create the file-system like this: > > # mkfs.ext3 -v -L myarray -m 0.5 -b 4096 -E stride=16...

...se of the problem. The next > question how to minimize the size of ldlinux.sys? > > BTW looking at official (?) binary > https://www.kernel.org/pub/linux/utils/boot/syslinux/Testing/6.03/syslinux-6.03-pre11.tar.xz > I see that their size is also more than 64K Actually, there is *no* 64KiB limit on btrfs. Look at btrfs-progs (ctree.h:830): " /* * We don't want to overwrite 1M at the beginning of device, even though * there is our 1st superblock at 64k. Some possible reasons: * - the first 64k blank is useful for some boot loader/manager * - the first 1M could be scrat...

...> For RAID-1 it doesn't really matter. >> >> Cheers, Andreas >> >>> On Mar 6, 2014, at 13:46, Martin T <m4rtntns@gmail.com> wrote: >>> >>> Hi, >>> >>> I created a RAID1 array of two physical HDD's with chunk size of 64KiB under Debian "wheezy" using mdadm. As a next step, I would like to create an ext3(or ext4) file-system to this RAID1 array using mke2fs utility. According to RAID-related tutorials, I should create the file-system like this: >>> >>> # mkfs.ext3 -v -L myarray -m 0.5 -b 4...

...R INC. physical id: 0 version: Rev 1.xx serial: 130207833100091 slot: To be filled by O.E.M. *-firmware description: BIOS vendor: American Megatrends Inc. physical id: 0 version: 1503 date: 01/11/2013 size: 64KiB capacity: 8128KiB capabilities: pci upgrade shadowing cdboot bootselect socketedrom edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer acpi usb biosbootspecification uefi *-pci:0 description: Host bridge p...

...but we see it doubled and it's not true because according Intel specification we know that this CPU have shared L2 cache. *grep 'cache size' /proc/cpuinfo * cache size : 6144 KB cache size : 6144 KB ################################### Here we can see that cpu have 6MiB L2 cache and 64KiB L1 cache *dmesg |grep 'CPU: L' * CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 6144K L2 - true L1 - not true because each CPU core have 64 KiB memory cache (Instruction and Data) ############################################ Into sys directory we can find some information abou...

...R_386_16 against `.bss1' isolinux-debug.o: In function `msg_viewimage': isolinux-debug.asm:(.text+0x2049): relocation truncated to fit: R_386_16 against `.bss1' ld: 64K overflow make: *** [isolinux-debug.elf] Error 1 Examining isolinux-debug.map, .bss1 seems to be ending just above the 64kiB mark, mostly because .adv gets incremented up (0xB200 to 0xB400). Am I correct in assuming that it would either require reworking the layout or adding another true segment to be able to handle this? Doing another true segment would probably require storing a handle in a .bss type section and initi...

...ZE - 512. > > > > > > Certain file systems (such as BTRFS and UFS2) will rely on ldlinux.sys > being installed on the 0-64k range, > > > thus it can't exceed the limit, otherwise the superblock would be > corrupted. > > Raphael/Paulo: does UFS2 have a hard 64kiB limit? I know it's not > installed to the first sector where the first superblock is located. > > > IMNSHO is including core/ldlinux_limit.pl better > > than waiting for a better core/ldlinux_limit.pl > > This should be rendered obsolete and unnecessary with the recent...

...The data32 prefix is almost never needed. If you use the correct suffix on an instruction (retl vs. retw, for example), then you should never need to use 'data32'. The addr32 prefix *is* needed by GNU binutils, because *even* when given an explicit address which is greater than 64KiB, it'll just give you a warning about truncation, and emit the instruction with a 16-bit addressing mode and the wrong address. LLVM doesn't do that, and is far happier to just use 32-bit addressing whenever it *might* need to. This means that we never really need an explicit add...

...tion physical id: 0 version: AAE62768-300 serial: BTGT931003W4 slot: To be filled by O.E.M. *-firmware description: BIOS vendor: Intel Corp. physical id: 0 version: GTG4310H.86A.0019.2009.0625.1334 (06/25/2009) size: 64KiB capacity: 960KiB capabilities: pci upgrade shadowing escd cdboot bootselect socketedrom edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer int10video acpi usb ls120boot zipboot biosbootspecification *-cpu descr...

...xsave avx lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid cpufreq configuration: cores=2 enabledcores=2 id=0 threads=4 *-cache:0 description: L1 cache physical id: 2 slot: L1-Cache size: 64KiB capacity: 64KiB capabilities: synchronous internal write-through data *-cache:1 description: L2 cache physical id: 3 slot: L2-Cache size: 256KiB capacity: 256KiB capabilities: sy...

On 05/20/2014 12:24 PM, Paulo Alcantara wrote: > > Actually, there is *no* 64KiB limit on btrfs. Look at btrfs-progs > (ctree.h:830): > > " > /* > * We don't want to overwrite 1M at the beginning of device, even though > * there is our 1st superblock at 64k. Some possible reasons: > * - the first 64k blank is useful for some boot loader/manage...

Op 2014-05-20 om 16:28 schreef H. Peter Anvin: > On 05/20/2014 12:24 PM, Paulo Alcantara wrote: > > > > Actually, there is *no* 64KiB limit on btrfs. Look at btrfs-progs > > (ctree.h:830): > > > > " > > /* > > * We don't want to overwrite 1M at the beginning of device, even though > > * there is our 1st superblock at 64k. Some possible reasons: > > * - the first 64k blank is...

...t; question how to minimize the size of ldlinux.sys? > > > > BTW looking at official (?) binary > > https://www.kernel.org/pub/linux/utils/boot/syslinux/Testing/6.03/syslinux-6.03-pre11.tar.xz > > I see that their size is also more than 64K > > Actually, there is *no* 64KiB limit on btrfs. Look at btrfs-progs > (ctree.h:830): > > " > /* > * We don't want to overwrite 1M at the beginning of device, even though > * there is our 1st superblock at 64k. Some possible reasons: > * - the first 64k blank is useful for some boot loader/manage...

On Sun, May 25, 2014 at 10:27 AM, Gene Cumm <gene.cumm at gmail.com> wrote: > Raphael/Paulo: does UFS2 have a hard 64kiB limit? I know it's not installed > to the first sector where the first superblock is located. Momentarily confused UFS2 and the madness of XFS putting its superblock into sector 0, rendering it unusable for typical boot purposes. -- -Gene

...dev, 0, false); - if (graphicsmode) /* graphics mode => framebuffer => no need to save */ + if (graphicsmode) /* graphics mode => framebuffer => no need to save */ return; NV_INFO(dev, "%sing VGA fonts\n", save ? "Sav" : "Restor"); + + /* map first 64KiB of VRAM, holds VGA fonts etc */ + iovram = ioremap(pci_resource_start(dev->pdev, 1), 65536); + if (!iovram) { + NV_ERROR(dev, "Failed to map VRAM, " + "cannot save/restore VGA fonts.\n"); + return; + } + if (nv_two_heads(dev)) NVBlankScreen(dev, 1, true); NVBlank...

...omething strange.. I think this is determined by kernel internals. It seems strange and problematic to me. I believe this number is controller dependant, so I'm wondering if I have a controller issue here... hda: max request size: 128KiB hdc: max request size: 1024KiB hdg: max request size: 64KiB hdi: max request size: 128KiB hdk: max request size: 1024KiB From all of this information, I believe my hard drives are somehow not tuned properly due to the low hdparm numbers, especially hda and hdc. This is causing the raid array to perform poorly, in dbench and hdparm -tT. The fact that t...